¿Cómo se realiza la unión de ramas (merge) o la sobrescritura de historia (rebase) en el sistema de control de versiones en su empresa?

En nuestro equipo, seguimos un flujo de trabajo basado en Git. Para integrar cambios, utilizamos dos enfoques principales: merge y rebase, eligiéndolos según la situación y el tipo de rama.

Merge:

• Se aplica generalmente para fusionar ramas de larga duración, por ejemplo, dev en main, o para integrar ramas de características en dev.
• Crea un commit de fusión que muestra claramente cuándo ocurrió la integración de cambios de otras ramas.
• Mantiene toda la historia de commits, incluyendo todas las bifurcaciones.

git checkout dev  // Cambiamos a la rama objetivo
git merge feature/nueva-funcionalidad  // Realizamos la fusión de la rama de característica

Rebase:

• Se usa para mantener una historia limpia y lineal en las ramas de características hasta su integración (normalmente en dev).
• Traslada los commits de la rama actual a la cima de la rama objetivo (dev), reescribiendo efectivamente la historia.
• Simplifica la historia, evitando commits de merge para cada pequeña característica o corrección.
• Importante: Nunca hagas rebase en ramas públicas en las que trabajan otros desarrolladores, ya que esto puede crear conflictos al intentar hacer pull de cambios.

git checkout feature/nueva-funcionalidad  // Cambiamos a la rama de característica
git rebase dev  // Trasladamos los commits de la rama de característica a la cima de dev
// Si es necesario, resolvemos conflictos
git push --force-with-lease  // Usamos --force-with-lease para un push seguro después del rebase

Nuestro flujo de trabajo estándar:

1. Se desarrolla una nueva característica o corrección en una rama separada (feature/..., fix/...).
2. Periódicamente (antes de un pull request o para sincronizar con dev), la rama de característica se rebasea en la versión actual de dev. Esto ayuda a resolver conflictos en etapas tempranas.
3. Después de completar el desarrollo y la revisión de código, la rama de característica se fusiona en dev con no-ff (no fast-forward), para mantener la información de la fusión. O, menos comúnmente, se hace un squash en un solo commit antes de fusionar en dev para cambios muy pequeños o correcciones.
4. Desde dev, se realizan lanzamientos periódicos en main (rama de producción), siempre mediante merge.

De esta manera, equilibramos la conservación de la historia de commits (merge) con el mantenimiento de una rama de desarrollo limpia (rebase de ramas de características).