Solicitud de extracción de GitHub que muestra confirmaciones que ya están en la rama de destino
Estoy intentando revisar una solicitud de extracción en GitHub para una rama que no es maestra. La rama de destino estaba detrás de master y la solicitud de extracción mostraba confirmaciones de master, así que fusioné master y la 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. Verifiqué dos veces que la rama en GitHub tenga las confirmaciones del maestro. ¿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.
Aquí tienes una buena solución. Utilice el Editbotón cuando vea el PR en GitHub para cambiar la rama base a otra que no sea master. Luego vuelva a cambiarlo mastery ahora mostrará correctamente solo los cambios de las confirmaciones más recientes.
Parece que la solicitud de extracción no realiza un seguimiento de los cambios en la rama de destino (me comuniqué con el soporte de GitHub y recibí una respuesta el 18 de noviembre de 2014 indicando que esto es por diseño).
Sin embargo, puede hacer que le muestre los cambios actualizados haciendo lo siguiente:
http://githuburl/org/repo/compare/targetbranch...currentbranch
Reemplace githuburl, org, repo, targetbranchy currentbranchsegún sea necesario.
O como señaló hexsprite en su respuesta, también puedes forzar su actualización haciendo clic Editen PR y cambiando temporalmente la base a una rama diferente y viceversa. Esto produce la advertencia:
¿Estás seguro de que quieres cambiar la base?
Es posible que algunas confirmaciones de la rama base anterior se eliminen de la línea de tiempo y que los comentarios de revisión antiguos queden obsoletos.
Y dejará dos entradas de registro en el PR:
En resumen, GitHub no cambia la base del historial de confirmaciones automáticamente en las solicitudes de extracción. Las soluciones más simples son:
Solución 1: Rebase
Supongamos que desea fusionarse masterdesde feature-01:
git fetch origin
git checkout feature-01
git rebase origin/master
git push --force-with-lease
Si está trabajando en una bifurcación, es posible que deba reemplazar originlo anterior 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
Supongamos 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.
Esto sucede con GitHub cuando aplastas las confirmaciones fusionadas desde la rama de destino.
Había estado usando squash y merge con Github como estrategia de fusión predeterminada, incluidas las fusiones desde la rama de destino. Esto introduce una nueva confirmación y GitHub no reconoce que esta confirmación aplastada es la misma que las que ya están en master (pero con diferentes hashes). Git lo maneja correctamente, pero vuelves a ver todos los cambios en GitHub, lo que hace que revisarlos sea molesto. La solución es realizar una combinación regular de estas confirmaciones ascendentes en lugar de combinarlas y combinarlas. Cuando desee fusionar otra rama con la suya como una dependencia git merge --squashy revertir esa única confirmación antes de salir de master una vez que esa otra rama haya llegado a master.
EDITAR: otra solución es rebase y forzar el empuje. Historia limpia pero reescrita
Para cualquier otra persona que se encuentre con esto y se sienta confundida por el comportamiento de GitHub Pull Request, la causa principal es que un PR es una diferencia entre la sugerencia de la rama de origen y el 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 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 basadas en ancestros comunes parecen peligrosas. Desearía que GitHub tuviera una opción para crear un PR basado en fusión de 3 vías más estándar.
EDITAR: nunca mencioné la solución alternativa obvia que siempre uso para evitar problemas que surjan de esto. Simplemente fusione su sucursal objetivo con su sucursal de relaciones públicas con regularidad y no se encontrará con sorpresas desagradables.
