Git Merge vs Git Rebase: Cómo tener un historial ordenado y claro

Si trabajas en equipo con Git, seguramente has escuchado sobre git merge y git rebase. Ambos sirven para combinar ramas, pero tienen efectos diferentes en la historia del repositorio. Usarlos correctamente puede hacer que tu historial de Git sea fácil de entender 🤩 o un desastre incomprensible 😵.

Vamos a ver en detalle en qué se diferencian y cuándo usar cada uno.

Git Merge

📌 ¿Qué hace Git Merge y por qué es útil??

Cuando usas git merge, Git toma dos ramas y las combina en una nueva confirmación (commit), manteniendo el historial de ambas ramas intacto. Se usa mucho cuando integras una rama secundaria en la principal (como develop o main).

Imagina que tienes dos caminos separados que finalmente se juntan en una carretera principal. Sigues viendo de dónde viene cada uno, pero ahora forman parte de la misma ruta.

🛠️ Cómo usar Git Merge y cómo se ve en los gráficos

Para aplicar merge a una rama llamada develop, es decir queremos enviar los cambios de feature/chatbot hacia develop. Primero debes posicionarte en la rama develop y ejecutar el siguiente comando:

git checkout develop
git merge feature/chatbot

Esto genera un commit de merge en develop con todo el historial de feature/chatbot.

Cómo debería verse un merge en el gráfico de historial de git.

Como puedes ver, hay una evidencia clara de que el branch feature/chatbot se incorporó en develop, lo hace muy fácil de leer.

En este caso no hubo conflictos. Sin embargo, sabemos que en un entorno productivo, el caos predomina 🔥, así que veamos un escenario más conflictivo.

🔍 Caso real: Cuándo usar Git Merge

Imagina que trabajas en un equipo desarrollando una nueva funcionalidad en una rama llamada feature/chatbot. Mientras tanto, otros compañeros han seguido trabajando en develop, agregando nuevas mejoras y correcciones de errores.

Llega el momento de integrar feature/chatbot en develop, pero quieres asegurarte de que el historial refleje claramente que esta funcionalidad se desarrolló en paralelo y luego se unió a la rama principal. Aquí es donde git merge brilla.

Se creará un commit de merge que preservará todo el historial de feature/chatbot, dejando claro cuándo y cómo se unieron los cambios. Esto es útil en proyectos colaborativos porque facilita el rastreo de la evolución del código y evita sobrescribir accidentalmente cambios de otros.

Sin embargo, dado que develop ha seguido evolucionando con cambios que no están en feature/chatbot, es probable que debas resolver conflictos de merge. Esto sucede porque algunos archivos pueden haber sido modificados en ambas ramas, y Git no sabe cuál versión debería mantenerse.

La solución consiste en revisar y seleccionar manualmente los cambios adecuados antes de finalizar el merge.

Una vez que solucionas los conflictos entre 2 ramas, el mismo conflicto no debería volver a aparecer (a menos que haya nuevas modificaciones en el archivo o clase que otro desarrollador ha modificado). Incluso si agregas un nuevo commit a feature/chatbot y vuelves aplicar merger hacia develop nuevamente.

Si en lugar de git merge intentáramos un git rebase, estaríamos reescribiendo la historia de feature/chatbot como si siempre hubiera estado basada en la última versión de develop. Esto podría generar problemas si otros colaboradores ya han trabajado sobre la misma rama y necesitan un historial claro de integración.

Por eso, git merge es la mejor opción aquí, ya que mantiene un historial fiel del desarrollo de la funcionalidad y facilita la colaboración en equipo.

Para los ejemplos del gráfico del historial de Git utilizo GitKraken Desktop, pero en cualquier cliente de Git deberías poder visualizarlo.

Git Rebase

📌 ¿Qué hace Git Rebase y por qué es útil??

git rebase toma los commits de una rama y los aplica sobre otra como si siempre hubieran estado allí. En lugar de mezclar con un commit de merge, reescribe la historia para que los cambios parezcan hechos directamente sobre la rama principal.

Es como si, en lugar de recordar que tomaste un desvío en el camino, tu GPS reescribiera el trayecto para que pareciera que nunca te desviaste.

También se podría usar para no dejar evidencia de cambios que vienen de una rama específica 👀 aparecen los commits pero no la rama del que vienen.

🛠️ Cómo usar Git Rebase y cómo se ve en los gráficos?

Para aplicar rebase a una rama llamada feature/oauth-gmail, la cual se creó anteriormente a partir de main. Primero debes posicionarte sobre la rama feature/oauth-gmail y ejecutar el siguiente comando:

git checkout feature/oauth-gmail
git rebase main

También podrías hacerlo desde un cliente de Git como Fork, Git Kraken u otro, presionando clic derecho a la rama que quieres aplicar rebase (como main) y seleccionar "rebase".

Esto generará que la rama feature/oauth-gmail se alinee con la rama main como si se hubiera creado con la ultima versión de main.

Cómo debería verse un rebase en el gráfico de historial de git.

🔍 Caso real: Cuándo usar Git Rebase

Imagina que estás trabajando en una nueva funcionalidad en una rama feature/oauth-gmail, la cual creaste a partir de master. Mientras tanto, master ha recibido múltiples actualizaciones, incluyendo hotfixes y nuevos releases.

Dado que feature/oauth-gmail proviene de master, lo ideal es hacer un git rebase master para alinear la rama con los cambios más recientes sin introducir un commit de merge innecesario.

Si en su lugar usaras git merge, se generaría una mezcla bidireccional entre master y feature/oauth-gmail, lo que haría más confusa la lectura del historial y rompería con la estrategia de branching.

Veamos como quedaría si queremos integrar con merge y luego queremos hacer un commit.

Como puedes ver, la rama master deja de tener un historial limpio 😖

Con git rebase master, los commits de feature/oauth-gmail se reordenan y aplican sobre la última versión de master, manteniendo un historial más limpio y lineal. Esto facilita la revisión del código y evita la complejidad innecesaria en el historial del proyecto.

Si hay conflictos, deberás resolverlos manualmente en cada paso del rebase, pero al final obtendrás una estructura más clara y organizada.

Incluso si quisiéramos hacer un nuevo commit quedaría más limpio tanto el historial de commits del feature como master.

Tanto con Git Merge como Git Rebase, no te salvarás de solucionar conflictos de merge. El propósito de estos comandos es mantener un historial de git de la forma más óptima para los desarrolladores y no tiene que ver con la forma de manejar los conflictos de merge.

🎉 Conclusión

Usa merge para integrar ramas de larga duración (como features hacia develop en Git Flow). Usa rebase para mantener actualizadas tus feature branches antes de mergearlas.

Tanto git merge como git rebase son herramientas poderosas y necesarias. No hay una "mejor" que otra, sino que cada una se adapta a diferentes situaciones. Si quieres un historial claro y ordenado, usa rebase. Si necesitas contexto y claridad en las integraciones, opta por merge.
Es importante que todo el equipo siga las mismas prácticas para mantener un historial de Git consistente.

¡Ahora sí, a escribir código y a hacer commits con confianza! 🚀