imagen

Haciendo rebase desde master

Rebase desde otra rama

En ocasiones cuando trabajamos en equipo, nuestros colegas están constantemente enviando cambios a la rama base del proyecto mediante merge que van siendo fusionados en diferentes momentos y tocando diferentes archivos del proyecto, y cuando nosotros sacamos una nueva rama desde la rama base del proyecto para empezar a trabajar en una nueva tarea, al final del día nos encontramos con cientos de cambios que han sido enviados a la rama base, pero que nosotros no tenemos en la rama que estamos trabajando dado que nuestra rama se creó con anterioridad, pero nos interesa poder traer esos cambios a nuestra rama para poder garantizar que nuestros cambios no están entrando en conflicto con ningún cambio que haya hecho recientemente uno de nuestros colegas, entonces es cuando toca ir a la rama base y traernos todos los commits que no estén en nuestra rama

Rama base, master o main 
C300---C301---C302---C303---C304---C305
  \
   \ B301---B302---B303      
     feature/h101

Supondremos que nosotros creamos nuestra rama feature/h101 cuando la rama base tenia como último commit el commit C300, pero mientras avanzábamos en nuestro trabajo, se sumaron varios commits más, desde el C301 al C305 y necesitamos traernos esos commits a desde master a nuestra rama feature/h101, para ellos haremos:

  • git checkout master Para cambiarnos a la rama master.
  • git pull origin master Para bajar los últimos commits que hayan en el repo remoto hasta ese momento.
  • git checkout feature/h101 para volver a nuestra rama
  • git rebase master para hacer un “rebase” de nuestra rama feature/h101 y traernos los cambios que no tenemos

Antes de hacer el rebase nuestra rama feature/h101 se veía así

rama feature/h101

C300---B301---B302---B303

Luego del rebase se vera algo así

rama feature/h101

 C300---C301---C302---C303---C304---C305---B306---B307---B308

Note que nuestros commits B301, B302, B303 ahora son B306, B307, B308 y pasaron al final del ultimo commit que tiene master actualmente

Cosa a considerar

  1. El hash de los commits de la rama base no van a cambiar, esto garantiza no generar conflictos cuando los subamos al repositorio remoto.
  2. El hash de cada uno de los nuestros últimos commit (B306 al B308) de nuestra rama van a cambiar cada vez que hagamos rebase, dado que rebase básicamente lo que hace es crear una nueva rama desde master y agregar al final de esta nuestros commits, esto no debería ser problema, dado que esos commit sólo están en nuestra rama local y pueden ser sobre escritos (rebase) cuantas veces sea necesario.
  3. Si la rama sobre la cual estas trabajando fue enviada al repositorio remoto, y aún no ha sido fusionada, aun puedes hacer rebase en local y volver a subir los cambios siempre y cuando nadie más haya enviado cambios a tu rama feature/h101, caso contrario se generarán conflictos al intentar hacer el push.
  4. Si después de hacer el rebase en local, intentas hacer el push al repositorio y te advierte que los hash de los commits no coinciden y que la rama diverge, esto se debe a que efectivamente en cada reorganización (rebase) tus últimos commit son sobre escritos y por consiguiente su hash cambia, si estás absolutamente seguro de que no hay commits de terceros en medio, puedes usar git push origin HEAD --force-with-lease
  5. --force-with-lease vs --force

    • --force: Sobrescribe el repositorio remoto de forma incondicional, borrando incluso commits que miembros de tu equipo pudieron haber subido. ¿Cuando usarlo? Nunca, salvo que quieras asegurarte de que la rama remota quede tal cual como la tienes en tu local incluso eliminando commit de otras personas.
    • --force-with-lease: Sobrescribe solo los commits que están en tu rama, asegurando no sobrescribir el trabajo de otros miembros del equipo. ¿Cuando usarlo? Siempre