tipos - git ver archivos modificados

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

Question

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, así que fusioné la maestra y la envié a GitHub, pero la confirmación y la diferencia para ellos aún aparecen en la solicitud de extracción después de actualizar. He comprobado el doble de que la sucursal en GitHub tiene las confirmaciones del maestro. ¿Por qué siguen apareciendo en la solicitud de extracción?

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

Answer 1

Aquí hay una buena solución. Use el botón Edit cuando vea el PR en GitHub para cambiar la rama base a otra que no sea la master . Luego, vuelva a cambiarlo a master y ahora solo mostrará correctamente los cambios de las confirmaciones más recientes.

Answer 2

En resumen, GitHub no rebase 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 desea fusionarse con el master desde la 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 el origin anterior por el anterior. Consulte ¿Cómo actualizo un repositorio bifurcado de GitHub? para obtener más información sobre el seguimiento de las sucursales remotas del repositorio original.

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

Supongamos que desea fusionar el intro master desde 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 para feature-01-rebased y cierre la de feature-01 .

Answer 3

Enfoque a prueba de fallos si está demasiado preocupado por desordenar las cosas: vaya al archivo y elimine manualmente los cambios, luego reprima con su último compromiso usando

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})"

Yo no hay conflictos, eres bueno para irte!

Answer 4

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

git pull --rebase

Esto recuperará y fusionará los cambios de su rama maestra de repositorio original (si tiene ese punto)

Luego empuja sus cambios a la fuerza a su repositorio clonado de github (destino)

git push -f origin master

Esto asegurará que su clon de github y su repositorio principal estén en el mismo nivel de confirmación de github y que no vea ningún cambio innecesario entre las sucursales.

Answer 5

Para cualquier persona que se encuentre con esto y se confunda con el comportamiento de la Solicitud de extracción de GitHub, la causa principal es que una PR es una diferencia de la punta de la rama de origen contra el antepasado 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 antepasado común y no tendrá en cuenta ningún cambio que pueda haber ocurrido 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. Me gustaría que GitHub tuviera la opción de hacer un PR estándar basado en fusión de 3 vías.

Answer 6

Parece que la Solicitud de extracción no realiza un seguimiento de los cambios en la rama de destino (contacté con el soporte de GitHub y recibí una respuesta el 18 de noviembre de 2014 que indica que se trata de un diseño).

Sin embargo, puede obtenerlo para mostrarle los cambios actualizados haciendo lo siguiente:

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

Reemplace githuburl , org , repo , targetbranch y currentbranch según sea necesario.

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

¿Seguro 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:

Answer 7

Una forma de solucionar esto es git rebase targetbranch en ese PR. Luego git push --force targetbranch , luego Github mostrará los compromisos y diferencias correctos. Tenga cuidado con esto si no sabe lo que está haciendo. Tal vez revise una rama de prueba primero para hacer la rebase y luego git diff targetbranch para asegurarse de que sigue siendo lo que desea.

Answer 8

~/.gitconfig agregar lo siguiente a su archivo ~/.gitconfig :

[rebase]
autosquash = true

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

Tengo esto de here .