Recientemente escribí en un blog sobre este tema:
¿Cómo mantenemos actualizada esta rama de funciones? Fusionar las confirmaciones ascendentes más recientes es fácil, pero desea evitar la creación de una confirmación de fusión, ya que eso no se apreciará cuando se empuje a las versiones ascendentes: entonces está re-confirmando efectivamente los cambios ascendentes, y esas confirmaciones ascendentes obtendrán un nuevo hash ( cuando tengan un nuevo padre). Esto es especialmente importante, ya que esas confirmaciones fusionadas se reflejarían en su solicitud de extracción de GitHub cuando envíe esas actualizaciones a su rama de funciones personal de GitHub (incluso si lo hace después de emitir la solicitud de extracción).
Es por eso que necesitamos reajustar en lugar de fusionar:
git co devel #devel is ansible's HEAD aka "master" branch
git pull --rebase upstream devel
git co user-non-unique
git rebase devel
Tanto la opción de rebase como el comando de rebase de git mantendrán tu árbol limpio y evitarán que se combinen confirmaciones. Pero tenga en cuenta que esas son sus primeras confirmaciones (con las que emitió su primera solicitud de extracción) que se están volviendo a basar y que ahora tienen un nuevo hash de confirmación, que es diferente de los hash originales que todavía están en su rama remota de repositorio de github. .
Ahora, enviar esas actualizaciones a su rama de características de GitHub personal fallará aquí, ya que ambas ramas difieren: el árbol de la rama local y el árbol de la rama remota están "desincronizados", debido a esos diferentes hashes de confirmación. Git te dirá que lo hagas primero git pull --rebase, luego presiona nuevamente, pero esto no será un simple avance rápido, ya que tu historial fue reescrito. ¡No hagas eso!
El problema aquí es que volvería a buscar sus primeras confirmaciones modificadas como estaban originalmente, y esas se fusionarán en la parte superior de su rama local. Debido al estado de desincronización, esta extracción no se aplica limpiamente. Obtendrá un historial roto donde sus confirmaciones aparecen dos veces. Cuando empuja todo esto a su rama de características de GitHub, esos cambios se reflejarán en la solicitud de extracción original, que se volverá muy, muy fea.
AFAIK, en realidad no hay una solución totalmente limpia para esto. La mejor solución que encontré es forzar el empuje de su sucursal local a su sucursal de GitHub (en realidad, forzando una actualización que no sea de avance rápido):
Según git-push (1):
Update the origin repository’s remote branch with local branch, allowing non-fast-forward updates. This can leave unreferenced commits dangling in the origin repository.
Así que no tire, simplemente empuje con fuerza así:
git push svg +user-non-unique
o:
git push svg user-non-unique --force
Esto en realidad sobrescribirá claramente su sucursal remota, con todo en su sucursal local. Las confirmaciones que están en la secuencia remota (y causaron la falla) permanecerán allí, pero serán confirmaciones colgantes, que eventualmente serán eliminadas por git-gc (1). No es gran cosa.
Como dije, esta es AFAICS la solución más limpia. La desventaja de esto es que su RP se actualizará con las confirmaciones más recientes, que tendrán una fecha posterior y podrían aparecer desincronizadas en el historial de comentarios del RP. No es un gran problema, pero podría resultar confuso.