Git - es tirar o rebase cuando se trabaja en ramas con otras personas

Git pull es una combinación de 2 comandos

• git fetch (sincroniza tu repositorio local con las cosas más recientes en el control remoto)
• git merge (fusiona los cambios de la rama distante, si los hay, en tu rama de seguimiento local)

Git rebase es solo un equivalente aproximado a git merge. No trae nada ni remotamente. De hecho, tampoco hace una combinación adecuada, repite las confirmaciones de la rama en la que estás parado después de las nuevas confirmaciones de una segunda rama.

Su propósito es principalmente permitirle tener una historia más limpia. No se necesitan muchas fusiones de muchas personas antes de que la historia pasada en Gitk se vuelva terriblemente espagueti.

La mejor explicación gráfica se puede ver en los primeros 2 gráficos aquí. Pero permítanme explicar aquí con un ejemplo.

Tengo 2 ramas: maestro y mi rama. Cuando estoy de pie en mybranch puedo correr

git rebase master

Y obtendré cualquier cosa nueva en master insertada antes de mis confirmaciones más recientes en mybranch. Esto es perfecto, porque si ahora merge o rebase las cosas de mybranch en master, mis nuevas confirmaciones se agregan linealmente justo después de las confirmaciones más recientes.

El problema al que se refiere sucede si rebase en la dirección "incorrecta". Si acabo de obtener el maestro más reciente (con nuevos cambios) y desde el maestro rebase así (antes de sincronizar mi rama):

git rebase mybranch

Lo que acabo de hacer es insertar mis nuevos cambios en algún lugar del pasado del maestro. La línea principal de confirmaciones tiene cambiar. Y debido a la forma en que git trabaja con los commits id, todos los commits (de master) que se reprodujeron en mis nuevos cambios tienen nuevos id.

Bueno, es un poco difícil de explicar solo con palabras... Espero que esto tenga un poco de sentido: -)

De todos modos, mi propio flujo de trabajo es este:

• ' git pull ' nuevos cambios desde el control remoto
• cambiar a mybranch
• 'git rebase master' para traer los nuevos cambios de master en mi historial de confirmaciones
• volver a master
• ' git merge mybranch', que solo avanza rápidamente cuando todo en master está también en mybranch (evitando así el problema de reordenamiento de commit en una rama pública)
• 'git push'

Una última palabra. Recomiendo encarecidamente el uso de rebase cuando las diferencias son triviales (por ejemplo, personas que trabajan en diferentes archivos o al menos diferentes líneas). Tiene el gotcha que intenté explicar justo allí, pero hace para una historia mucho más limpia.

Tan pronto como pueda haber conflictos significativos (por ejemplo, un coworker ha cambiado el nombre de algo en un montón de archivos), recomiendo encarecidamente combinar. En este caso, se le pedirá que resuelva el conflicto y luego confirme la resolución. En el lado positivo, una fusión es mucho más fácil de resolver cuando hay conflictos. El lado negativo es que su historia puede ser difícil de seguir si mucha gente se fusiona todo el tiempo: -)

¡Buena suerte!