Solicitud de extracción de GitHub que muestra confirmaciones que ya están en la rama de destino


136

Estoy tratando de revisar una solicitud de extracción en GitHub a una sucursal que no es maestra. La rama de destino estaba detrás del maestro y la solicitud de extracción mostraba confirmaciones del maestro, por lo que fusioné el maestro y lo envié a GitHub, pero las confirmaciones y diferencias para ellos todavía aparecen en la solicitud de extracción después de la actualización. He comprobado dos veces que la rama en GitHub tiene los commits de master. ¿Por qué siguen apareciendo en la solicitud de extracción?

También revisé la solicitud de extracción localmente y solo muestra las confirmaciones no fusionadas.


¿Afecta esto el comportamiento de fusionar el PR?
Nathan Hinchey

No, solo la diferencia en Github.
lobati

¿Alguien sabe si Gitlab autohospedado sufre el mismo comportamiento?
Jeff Welling el

2
Sugiero que todos nos comuniquemos con GitHub para expresar nuestro interés en cambiar este comportamiento ( support.github.com/contact ). Si no tienen noticias nuestras, entonces no sabrán cuán importante es esto y así será para siempre.
steinybot

Respuestas:


107

Parece que la solicitud de extracción no realiza un seguimiento de los cambios en la rama objetivo (contacté con el soporte de GitHub y recibí una respuesta el 18 de noviembre de 2014 que indica que esto es así por diseño).

Sin embargo, puede hacer que le muestre los cambios actualizados haciendo lo siguiente:

http://githuburl/org/repo/compare/targetbranch...currentbranch

Reemplazar githuburl, org, repo, targetbranch, y currentbranchcuando sea necesario.

O como señaló hexsprite en su respuesta, también puede forzarlo a actualizar haciendo clic Editen el RP y cambiando temporalmente la base a una rama diferente y viceversa. Esto produce la advertencia:

¿Estás seguro de que quieres cambiar la base?

Algunas confirmaciones de la rama base anterior pueden eliminarse de la línea de tiempo y los comentarios de revisión anteriores pueden quedar desactualizados.

Y dejará dos entradas de registro en el PR:

ingrese la descripción de la imagen aquí


44
Sí, contacté a soporte hace un tiempo y obtuve la misma respuesta. No optimizan para esta situación. Es un poco frustrante. Nuestra forma de evitarlo es simplemente rebase y forzar el empuje hacia arriba, o cerrar el tirón y crear uno nuevo.
lobati

44
Esta respuesta no soluciona el problema, pero solo permite al usuario ver la diferencia verdadera.
FearlessFuture

44
La pregunta era "¿Por qué siguen apareciendo en la solicitud de extracción?". Responde a esa pregunta.
Adam Millerchip

3
Mira mi comentario para una buena solución. Simplemente puede usar el botón de edición PR para cambiar a otra rama y luego volver a la rama base original y volverá a calcular la diferencia.
hexsprite

11
¿Hay una solicitud de dear-github para cambiar esto?
vossad01

87

Aquí hay una buena solución. Use el Editbotón cuando vea el PR en GitHub para cambiar la rama base a algo diferente master. Luego vuelva a cambiarlo mastery ahora mostrará correctamente solo los cambios de las confirmaciones más recientes.


44
Me sorprende que más personas no reconozcan esta solución. Sospecho que la solicitud de extracción original desactualizada estaría bien, pero no me gustó que GitHub muestre todos los archivos desactualizados, así que utilicé esto y ambos mantienen el comentario y solo muestran los cambios reales a punto de fusionarse . ¡Gracias!
taranaki

2
No funciono para mi.
Shashank

¡Maldita sea, esto funciona!
Anurag Hazra

Tres años después y esta sigue siendo una gran solución. Y mira, alguien también comentó hace unas horas también ^^^
Ricardo Saporta

32

En resumen, GitHub no modifica el historial de confirmación automáticamente en las solicitudes de extracción. Las soluciones más simples son:

Solución 1: Rebase

Supongamos que se desea combinar en masterdesde feature-01:

git fetch origin
git checkout feature-01
git rebase origin/master
git push --force

Si está trabajando en una bifurcación, es posible que deba reemplazar la originanterior con upstream. Consulte ¿Cómo actualizo un repositorio bifurcado de GitHub? para obtener más información sobre el seguimiento de ramas remotas del repositorio original.

Solución 2: cree una nueva solicitud de extracción

Suponga que desea fusionar la introducción masterde feature-01:

git checkout feature-01
git checkout -b feature-01-rebased
git push -u origin feature-01-rebased

Ahora abra una solicitud de extracción feature-01-rebasedy cierre la de feature-01.


44
Una nueva versión cambia los hashes de confirmación, por lo que terminaría destruyendo los comentarios de revisión existentes?
haridsv

@haridsv Probablemente sí.
Mateusz Piotrowski

¿Algo a tener en cuenta al hacer fuerza?
Paul Bendevis

1
@haridsv esa no es mi experiencia. Frecuentemente rebaso la mitad de la revisión y los comentarios no se pierden. Aunque pierdo la historia de los cambios en las relaciones públicas
joel

@JoelBerkeley Mientras tanto, experimenté un par de críticas en las que el autor rebasó y observó que los comentarios están intactos. Sin embargo, perdemos la capacidad de revisar de forma incremental y para revisiones grandes es una gran penalización para los revisores. Ahora tenemos algunas pautas para nuestros RP y una de ellas es nunca volver a redactar una vez abierta la revisión (a menos que uno esté seguro de que nadie comenzó a revisar todavía). La fusión está bien, pero nuestra directriz es no mezclar el cambio de fusión con ningún otro cambio que no sea la resolución de conflictos.
haridsv

17

Debe agregar lo siguiente a su ~/.gitconfigarchivo:

[rebase]
    autosquash = true

Esto logrará automáticamente lo mismo que muestra esta respuesta .

Tengo esto de aquí .


2
maldición, hice clic en votar hacia abajo accidentalmente. Esta respuesta me ayudó. déjame cambiarlo por favor.
Hector

@hosein A por ello. Deberías poder hacerlo ahora.
Mateusz Piotrowski el

1
Creo que esta debería ser la respuesta aceptada o incluida en la respuesta aceptada. ¡Esto logra el resultado que estaba buscando!
Ronald Rey

1
@RonaldRey git rebasing no es una solución universal, porque implica editar el historial. Si todo el mundo está trabajando en tenedores privados que nunca han sido clonados por otros, entonces está bien, pero tan pronto como alguien clone su repositorio y luego edite el historial, terminará con diferentes historias.
Adam Millerchip

14

Para cualquier otra persona que se encuentre con esto y esté confundido por el comportamiento de la solicitud de extracción de GitHub, la causa raíz es que un RP es una diferencia de la punta de la rama de origen frente al ancestro común de la rama de origen y la rama de destino. Por lo tanto, mostrará todos los cambios en la rama de origen hasta el ancestro común y no tendrá en cuenta los cambios que puedan haberse producido en la rama de destino.

Más información disponible aquí: https://developer.atlassian.com/blog/2015/01/a-better-pull-request/

Las diferencias comunes basadas en ancestros parecen peligrosas. Desearía que GitHub tuviera la opción de hacer un RP más estándar basado en fusión de 3 vías.


1
La razón que mencionó parece correcta, pero estoy confundido porque generalmente cada vez que el maestro se actualiza, vuelvo a fusionar los cambios en mi rama ... git checkout my-branch -> git merge master . La solicitud de extracción se actualiza de inmediato. ¿El antepasado común también se actualiza?
G.Uno

2
Este comportamiento parece ocurrir cuando se realiza un rebase en lugar de una fusión
G.One

1
@ G.Una respuesta muy tardía, pero sí, si se fusiona desde esa rama maestra a su rama fuente, por definición ha actualizado el antepasado común. Es el compromiso con el maestro del que te uniste.
David K. Hess

13

Una forma de arreglar esto es git rebase targetbranchen ese PR. Luego git push --force targetbranch, Github mostrará los commits y diff correctos. Tenga cuidado con esto si no sabe lo que está haciendo. Tal vez revise una rama de prueba primero para hacer el cambio de base y luego git diff targetbranchpara asegurarse de que sigue siendo lo que desea.


10

Esto sucede con GitHub cuando las confirmaciones de squash se fusionan desde la rama de destino.

Había estado usando squash y fusionar con Github como la estrategia de fusión predeterminada, incluidas las fusiones de la rama de destino. Esto introduce un nuevo commit y GitHub no reconoce que este commit aplastado es el mismo que los que ya están en master (pero con diferentes hashes). Git lo maneja correctamente, pero vuelve a ver todos los cambios en GitHub, por lo que es molesto revisarlo. La solución es hacer una fusión regular de estas confirmaciones en sentido ascendente en lugar de una fusión y fusión. Cuando desee fusionarse en otra rama en la suya como una dependencia, git merge --squashy revertir esa confirmación única antes de extraer de master una vez que esa otra rama haya llegado a master.

EDITAR: otra solución es rebase y forzar empuje. Historia limpia pero reescrita


1
Gracias @achille, este fue realmente el problema de mi parte. Después de deshabilitar la fusión de la calabaza, se resuelve.
Ashvin777

0

No estoy exactamente seguro de la teoría detrás de esto. Pero obtuve esto varias veces y pude solucionarlo haciendo lo siguiente.

git pull --rebase

Esto buscará y fusionará los cambios de su rama maestra de repositorio original (si tiene algo que ver con eso)

Luego empujas tus cambios con fuerza a tu repositorio clonado de github (objetivo)

git push -f origin master

Esto asegurará que su clon de github y el repositorio principal estén en el mismo nivel de confirmación de github y que no vea cambios innecesarios en las ramas.


0

Pruebe los siguientes comandos, uno por uno.

git pull "latest

git reset --hard master

-1

Enfoque a prueba de fallas si está demasiado preocupado por arruinar las cosas: vaya al archivo y elimine manualmente los cambios, luego aplastar con su última confirmación utilizando

git add .  && git commit -a --allow-empty-message -m '' && git reset --soft HEAD~2 &&
git commit --edit -m"$(git log --format=%B --reverse HEAD..HEAD@{1})"

Si no hay conflictos, ¡estás listo para irte!

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.