Una excelente manera de evitar conflictos y mantener el paradigma de responsabilidad única es utilizar ramas para asegurarse de que las diferentes partes del desarrollo estén aisladas.
Sin embargo, no podemos esperar que nuestro proyecto permanezca en fragmentos para siempre, necesitamos ensamblarlos para acceder a un programa completamente funcional.
Ahí es donde entra en juego la fusión (merging). Como su nombre sugiere, es la unión de dos ramas. O, para ser más precisos, es la incorporación de los commits de la rama B a la rama A.
Merging
Por ejemplo, si estás escribiendo código para una nueva feature de tu programa y decides usar una nueva rama para eso. No hay problemas hasta ahí, pero ¿qué sucede cuando terminas la nueva feature y necesitas integrarla al proyecto completo?
Para lograrlo, cambia a la rama main.
bashgit checkout main
Luego, solo es cuestión de llevar los commits de la rama con la feature a esta rama y fijarlos con un commit de merge.
bashgit merge feature_branch
La dirección de la fusión siempre es traer desde la rama especificada a la rama actual y traerá hasta el último commit
Sin embargo, eso no significa que siempre fusionaremos desde una rama feature hacia la rama principal. A veces ocurre lo contrario.
Si estabas trabajando en una feature en una rama específica y se realizaron nuevos cambios en la rama main y esos cambios son relevantes para tu feature, es posible que desees mantener esas actualizaciones.
El procedimiento sería un poco diferente. En lugar de cambiar a main, estarías en la rama de la feature y fusionarías las nuevas adiciones desde main.
bashgit merge main
A partir de entonces, los nuevos cambios se habrán incorporado a la rama. Además, ambas ramas se mantendrán, sin cambios adicionales.
Una posible desventaja de la fusión es llevar un seguimiento del historial de las ramas. El proceso de fusión resultará en muchos más commits descritos, lo que puede considerarse como una contaminación del historial, especialmente si la rama principal está muy activa y se deben fusionar commits de ella con frecuencia.
Rebasing
El rebasing es una alternativa al merge, que también conduce a la integración de un nuevo trabajo en una rama diferente. Sin embargo, el rebasing no preservará el historial de la rama.
Mientras que el merge creará un nuevo commit para cada integración que muestra cómo y cuándo se combinaron las ramas, el rebasing procederá de manera ligeramente diferente.
Por ejemplo, si quisiéramos hacer un rebasing de la rama "feature" en la rama "main", el rebasing reescribirá el historial de la rama "feature" para que parezca que su inicio fue el último estado de "main" y que los commits de "feature" fueron secuenciales a los de "main".
Esto convertirá lo que era un proyecto paralelo, desarrollado en varias ramas, en uno lineal, como si hubiera sido creado en una sola rama.
Esto resulta en un historial mucho más claro, más fácil de usar con git log o git bisect.
La regla de oro del Rebasing
Como puedes imaginar, reescribir el historial de un repositorio puede ser peligroso si se hace en la situación equivocada. Afortunadamente, hay una "regla de oro" para el rebasing:
Nunca hagas un rebasing en una rama pública.
Si hicieras un rebasing de "main" en tu rama "feature", terminarías con una "main" completamente diferente a la de los demás.