Mantén tu historial de Git limpio con git merge –squash

Si has trabajado en una rama de feature en Git, sabes cómo se acumulan commits irrelevantes: pruebas rápidas, arreglos de estilo, mensajes como “fix typo” o “ajuste de padding”. Cuando llega el momento de hacer merge con main, ese caos amenaza con colarse en el historial principal.

¿La solución? git merge --squash. Este comando es mi herramienta favorita para limpiar el historial antes de integrar cambios. Te permite combinar todos los commits de una rama en uno solo, como si los hubieras escrito de una sola vez (aunque tú y yo sabemos que hubo sudor de por medio).

¿Qué hace exactamente --squash?

git merge --squash feature/login

Este comando no hace un merge tradicional. Lo que hace es aplicar todos los cambios de la rama feature/login sobre tu rama actual (por ejemplo, main) como un gran bloque de código listo para ser commiteado manualmente. Es como si hicieras un stash pop, pero más elegante.

No verás un commit de merge, ni Git marcará una relación directa entre ambas ramas. Tú decides el mensaje del commit y qué incluir. Es el equivalente gitiano de pasar una escoba antes de invitar gente a casa.

Ventajas de usar squash

• Historial limpio: un solo commit por funcionalidad, sin basura técnica.
• Commits con propósito: tú eliges el mensaje y haces que tenga sentido.
• Evita ruido: no arrastras commits innecesarios como “corrijo sangría”.

Flujo recomendado de squash

Este es el proceso que sigo cada vez que quiero fusionar una rama de forma limpia:

# Cambia a main y actualiza la rama
git checkout main
git pull origin main

# Aplica los cambios de la rama feature como un solo bloque
git merge --squash feature/login

# Realiza el commit único
git commit -m "feat: implementa login con validación y tests"

# Sube los cambios
git push origin main

# Elimina la rama si ya no la necesitas
git branch -d feature/login
git push origin --delete feature/login

Este patrón lo uso siempre que trabajo con ramas pequeñas o medianas. Para features grandes, prefiero dividir en ramas temáticas y luego squash cada una.

¿Cuándo evitar --squash?

No todo es color de rosas. Hay escenarios donde hacer squash puede jugar en tu contra:

• Necesitas conservar el historial: por ejemplo, para revisar cómo evolucionó una feature compleja.
• Trabajo colaborativo: si varios desarrolladores trabajan en la misma rama, hacer squash puede dificultar el seguimiento y generar conflictos.
• Planeas hacer un merge real más adelante: Git puede confundirse y terminar con conflictos evitables.

Consejos prácticos

• Haz squash justo antes de cerrar una rama, no en medio del desarrollo.
• Evita mezclar squash y merges normales en la misma rama. El historial se vuelve impredecible.
• En plataformas como GitHub o GitLab, puedes hacer squash directamente al aceptar un pull request. Solo asegúrate de revisar el mensaje final.

Personalmente, uso squash casi siempre en proyectos personales y también cuando lidero equipos pequeños. La diferencia en la claridad del historial se nota enseguida: menos commits basura, más enfoque en el qué en lugar del cómo.

Un último consejo: piensa en el futuro tú

Cuando veas el historial de main dentro de seis meses, te alegrarás de ver commits con sentido como feat: agrega login con OAuth en vez de una tormenta de «fix» y «ajuste menor». Usar squash no solo es orden, es también respeto por tu yo del futuro.

¿Tú ya lo usas en tu flujo diario? ¿O prefieres mantener el historial completo? Me encantaría saber cómo gestionas tus ramas.