Git Rebase vs Merge: Cuándo y Por Qué Usar Cada Uno
Git
¿Qué es Git?
Git es un sistema de control de versiones que te permite hacer un seguimiento de todos los cambios que realizas en una base de código o repositorio. Permite una colaboración efectiva y que varias personas trabajen en el mismo código.
Existen algunos conceptos que debes conocer: repositorios, PRs, ramas y commits.
Una vez que aprendas más sobre estos conceptos, puedes comenzar a usar Git en tus propios proyectos.
No cubriré lo básico en este artículo, ya que hay una gran cantidad de detalles. Si aún no has trabajado con Git, hay una guía completa para principiantes en StackOverflow.
Sin embargo, hay algunas cosas importantes que debes saber, especialmente si trabajas con varias personas en el mismo proyecto o función.
Lo primero que debes aprender es cómo usar las ramas efectivamente. Esto te permite dividir el trabajo en características, correcciones y lanzamientos, lo que facilita trabajar en una característica separada y mantener ciclos de lanzamientos una vez que tu proyecto se vuelve más complejo.
Modelo de Ramas
Normalmente, trabajas en ramas de feature1 y hotfix. Una vez que el desarrollo de una feature cumple con su DoD, puede ser fusionada con la rama release2 actual. Tiene sentido tener ramas release que acumulen características y correcciones de errores hasta que se cumplan los requisitos para la próxima versión3.
1 - Las características representan un aumento en el valor del producto y generalmente son auto contenidas. Tiene sentido tener una rama separada para cada característica, ya que contiene todos los cambios necesarios para un aumento en el valor.
2 - En el desarrollo de productos, generalmente tienes ciclos de lanzamiento. Un lanzamiento es una colección de características que marca una versión finalizada de un producto.
3 - Esto significa que todas las características cumplen con su DoD, todas las pruebas se ejecutan con éxito, QA y Diseño están aprobados. Los linters y compiladores no producen errores y la pipeline está verde (se ejecuta con éxito).
Una vez que una rama de lanzamiento esté lista y se haya desplegado en producción, debe ser finalizada (bloqueada). Luego, puedes fusionarla con master y etiquetar el commit con el número de versión correcto.
Aquí hay un artículo de Atlassian que cubre diferentes flujos de trabajo de ramas, como GitFlow.
Una vez que te familiarices con las ramas, características y ciclos de lanzamiento, puedes intentar colaborar con otros en un proyecto.
Hay algunas cosas que debes saber al trabajar juntos en la misma rama de característica.
Algunas de estas son el rebase al upstream y la preservación del historial al fusionar.
¿Cuál es la diferencia entre git rebase y git merge?
Consulta esta pregunta
¿Cuándo usar git rebase y cuándo git merge?
Ambos, hacer merge y rebase, son a veces necesarios, y es bastante fácil saber cuál es el adecuado.
Depende del estado de tu rama local y la dirección de los cambios que estás extrayendo / enviando.
Si otra persona hizo cambios en la misma rama mientras trabajabas en tus ramas locales, necesitarás rebasar la rama remota antes de fusionar tus commits en el remoto.
Supongamos que estás trabajando con varias personas en la misma rama de características. Mientras trabajas en tu característica local, otra persona ya fusionó / subió sus cambios a la rama remota de la característica. Ahora, si deseas fusionar tus cambios en la misma rama remota, primero necesitas obtener los cambios hechos en upstream.
Aquí es donde entra el rebase. Esto moverá tus commits locales detrás o encima de los cambios realizados en la rama remota por otros y resultará en un historial de commits lineal, que se puede fusionar de manera limpia en la rama remota.
Ahora surge otra pregunta. ¿Cómo fusionas una rama de feature en una rama de release?
Básicamente, tienes dos opciones: --no-ff y --squash
¿Cuál es la diferencia entre --no-ff y --squash?
Estas son dos opciones importantes que afectan cómo se ve tu historial de commits, lo cual, a su vez, afecta cuán fácil es revertir cambios en una etapa posterior.
En general, se debe preferir la simplicidad, y un historial lineal es más simple que uno con commits de merge complicados.
Al fusionar una serie de commits (una característica) en tu rama de lanzamiento, puedes elegir si deseas mantener cada commit individual de la rama de características en el historial (--no-ff), o si deseas combinar todos los commits en un solo commit con un solo mensaje (--squash).
El comportamiento predeterminado de la fusión simplemente avanza rápidamente tu HEAD hasta el final de tu rama de características, lo que pierde la información de que una característica se desarrolló en una rama separada, pero mantiene todos los commits con sus mensajes individuales.
Los mensajes de commit son importantes porque pueden mostrarse en tu IDE junto a la línea de código, lo que es muy útil cuando trabajas con otros.
Por otro lado, --squash aplana todos los commits en un solo commit, lo que significa que cada línea en un blame muestra el mismo mensaje.
Esto está bien en muchos casos, pero debes ser consciente de que si deseas revertir algo más tarde, solo podrás revertir el commit completo aplastado, no partes de él.
El comando más preciso que puedes usar para preservar el historial, los mensajes de commit para los blames y la posibilidad de revertir commits individuales es:
git merge feat/my-feature --no-ff
IMHO, esto debería ser el estándar, y deberías elegir activamente hacer un avance rápido (lo cual es adecuado en algunos casos).
Creo que estas son algunas de las cosas más importantes que debes saber sobre git y, si dominas todo esto, usar git será pan comido.
Nota: Hay aún más cosas que puedes hacer en git, como bisectar, lo cual es muy útil y algo que todo desarrollador intermedio o senior debería saber cómo usar, pero eso se cubrirá en otro post.