La opción rebase en Git
Lección 53 / 53
Git Guía Git Guía Git español
Al elegir la opción de rebase en Git para recuperar los cambios principales en las funciones, se "mueve" toda la función de rama y se recrean los commit individuales que formaban parte de ella.
git checkout feature
git rebase main
Opción Rebase
La ventaja de la opción de rebase en Git es precisamente la posibilidad de obtener un historial de proyecto más claro. El commit de merge ya no existe y el historial del proyecto está más ordenado (en términos de lo que pasó a formar parte de la rama principal).
Sin embargo, hay dos compromisos a considerar:
- con el rebase no será posible saber cuando los cambios del branch principal han sido reportados en el branch feature
- si no se sigue la regla del rebase, se tendrá que estar listo para gestionar problemas de colaboración entre web developers
La regla del rebase en Git
Nunca hacer rebase en un branch público
Para entender mejor el porqué de esta regla, supongamos que para incorporar los cambios presentes en las dos ramas hubiéramos optado por hacer rebase de la rama principal en la rama feature. Habríamos obtenido la siguiente situación:
Opción Rebase
El rebase mueve todos los commit anteriores en main a la sugerencia de feature, creando nuevos commit. Pero eso solo sucede en su repositorio local. Dado que el rebase da como resultado commit completamente nuevos, Git pensará que el historial de su rama principal se ha desviado de ese repositorio remoto y no podrá enviar a menos que use la opción --force.
Al elegir hacer push con force, en realidad podríamos realinear nuestros repositorios locales y remotos, pero todos los demás colaboradores aún tendrán la rama principal original y no les será posible actualizar de manera simple sus repositorios.
Por supuesto, como todas las reglas, hay momentos en los que es necesario romperlas. Obviamente, todo depende del proyecto, del equipo y de la necesidad. De hecho, es posible acordar reescribir el historial de una feature branch publicada en el repositorio remoto antes de fusionarla con la rama principal (por ejemplo, porque la fusión tiene conflictos y desea resolver estos conflictos cambiando directamente los commit en la rama que entra en conflicto) y verificar si la resolución realmente deja todo funcionando.
Lo importante es saber qué estás haciendo y sobre quién, si es que hay alguno, tiene un impacto.
Anterior
52 La opción merge en ..Siguiente
54