Técnicas para que hacer rebase dé menos dolores de cabeza
En esta página
Veo a menudo a desarrolladores fusionar main en sus ramas de función y abrir pull requests (PR) que incluyen commits de otras ramas. Esta práctica lleva al “espagueti de git”, con varias consecuencias:
- Complica el historial de commits
- Aumenta el riesgo de conflictos que a los demás les cuesta resolver
- Puede colar cambios que no están listos para
main - Estorba la revisión de código, porque los cambios ajenos distraen del propósito real del PR
Haz un soft reset antes de hacer rebase
Usa git reset para rebobinar hasta el punto en el que tu rama se separó de la rama principal. Así tus cambios quedan intactos en el directorio de trabajo, listos para commitearlos de una forma más limpia y ordenada.
git reflog # Identify the divergence point
git reset commit_sha # Soft reset to this point
Ventajas:
- Conserva tus cambios en el directorio de trabajo
- Simplifica el rebase al reducir el número de commits que gestionar
- Da un historial de commits más limpio y con más sentido
- Menos presión a la hora de elegir un mensaje de commit, porque los aplastas todos en uno
Haz fetch en vez de pull
Ejecuta git fetch para actualizar tu repositorio con lo último del remoto sin fusionar automáticamente esos cambios en tu rama local. Así tienes la oportunidad de revisar los cambios antes de decidir cómo integrarlos.
git fetch origin
git rebase origin/main # Rebase your branch on the updated main branch
Ventajas:
- Te deja decidir cuándo incorporar los cambios nuevos de tu equipo
- Mejora tu comprensión de los commits nuevos antes de fusionar o hacer rebase
- Ayuda a mantener un historial de commits lineal y limpio