← Todos los artículos

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