Merge como Estrategia de Actualización
La estrategia estándar para mantener la rama de trabajo sincronizada con main es merge, no rebase. El rebase queda estrictamente prohibido como práctica estándar.
¿Por qué merge y no rebase?
📜Pérdida de historial original: al hacer rebase se reescribe el historial del commit y se pierde la referencia de dónde se comenzó la implementación.
⚙️Fricción innecesaria: implica una dependencia constante de hacer rebase, generando carga operativa para todos los miembros del equipo.
⚠️Requiere conocimiento avanzado: solo es manejable de forma segura por desarrolladores mid/senior. Para juniors, los conflictos en rebase son significativamente más confusos que en merge.
🔁Conflictos recurrentes: cada rebase puede reintroducir conflictos que ya fueron resueltos previamente.
💥Riesgo de pérdida de trabajo: un rebase mal ejecutado puede destruir commits.
Estrategia estándar — Merge
# Sincronizar feature branch con main
git checkout feat/456-login-con-google
git fetch origin main
git merge origin/main
# Resolver conflictos si existen
git push origin feat/456-login-con-google
Buena práctica: Hacer esto periódicamente — al menos al comenzar cada día de trabajo — para minimizar conflictos al momento del MR.
Excepciones controladas
El rebase interactivo (git rebase -i) puede utilizarse únicamente cuando:
🧹Es explícitamente necesario — por ejemplo, limpiar commits basura antes de un MR.
👤Es realizado por el autor de la rama o por un Maintainer del repositorio.
🚫No es una práctica obligatoria ni recurrente.
Nota: Los squashed commits no son responsabilidad de los devs. El squash se realiza automáticamente por el mecanismo del Merge Request al integrar a main.
El rebase está prohibido como práctica estándar. Usarlo sin el conocimiento necesario puede destruir commits y generar conflictos recurrentes.
