Blog

Conflictos por rebase

Conflictos por rebase

Estaba hoy en una rama en la que había trabajado previamente, y otro compañero ha hecho posteriormente un rebase (supongo que también un push force). Al taerme los cambios con git pull, resultaban conflictos:

j@bt ~/Documents/trabajo/acme/tmp/repo (feature/TAREA) % git log
commit HASH_ANTIGUO_1 (HEAD -> feature/TAREA)
Author: Yo
Date:   Thu Dec 9 23:41:34 2021 +0100

    chore: [TAREA] COMENTARIO_1

commit HASH_ANTIGUO_2
Author: Yo
Date:   Thu Dec 9 23:11:30 2021 +0100

    feat: [TAREA] COMENTARIO_2

commit HASH_MERGE_FEATURE_1
Merge: X X
Author: G
Date:   Thu Dec 2 15:36:03 2021 +0000

    Merge branch 'feature/TAREA_MERGEAR_1' into 'master'
    
    [TAREA_MERGEAR_1] COMENTARIO_TAREA_MERGEAR_1
    
    See merge request producto/repo/back-end/repo!451
j@bt ~/Documents/trabajo/acme/repo (master) % git checkout feature/TAREA
Switched to branch 'feature/TAREA'
Your branch and 'origin/feature/TAREA' have diverged,
and have 2 and 25 different commits each, respectively.
  (use "git pull" to merge the remote branch into yours)
j@bt ~/Documents/trabajo/acme/repo (feature/TAREA) % git pull
hint: Pulling without specifying how to reconcile divergent branches is
hint: discouraged. You can squelch this message by running one of the following
hint: commands sometime before your next pull:
hint: 
hint:   git config pull.rebase false  # merge (the default strategy)
hint:   git config pull.rebase true   # rebase
hint:   git config pull.ff only       # fast-forward only
hint: 
hint: You can replace "git config" with "git config --global" to set a default
hint: preference for all repositories. You can also pass --rebase, --no-rebase,
hint: or --ff-only on the command line to override the configured default per
hint: invocation.
Auto-merging ...
# [Muchos conflictos]
Automatic merge failed; fix conflicts and then commit the result.
j@bt ~/Documents/trabajo/acme/repo  (git)-[feature/TAREA|merge]- % git merge --abort
j@bt ~/Documents/trabajo/acme/tmp/repo (feature/TAREA) % git log --pretty=%P -n 1 "HASH_ANTIGUO_2"
HASH_MERGE_FEATURE_1
j@bt ~/Documents/trabajo/acme/repo (feature/TAREA) % git reset --hard origin/feature/TAREA
HEAD is now at 9df6977c feat: COMENTARIO_3
j@bt ~/Documents/trabajo/acme/repo (feature/TAREA) % git log
commit OTRO_COMMIT (HEAD -> feature/TAREA, origin/feature/TAREA)
Author: N
Date:   Tue Jan 4 18:26:04 2022 +0000

    feat: COMENTARIO_3

commit HASH_NUEVO_1
Author: Yo
Date:   Thu Dec 9 23:41:34 2021 +0100

    chore: [TAREA] COMENTARIO_1

commit HASH_NUEVO_2
Author: Yo
Date:   Thu Dec 9 23:11:30 2021 +0100

    feat: [TAREA] COMENTARIO_2

commit HASH_MERGE_FEATURE_2 (tag: TAREA_MERGEAR_2)
Merge: X X
Author: Yo
Date:   Thu Dec 16 23:34:14 2021 +0000

    Merge branch 'release/TAREA_MERGEAR_2' into 'master'
    
    [TAREA_MERGEAR_2] version TAREA_MERGEAR_2
    
    See merge request producto/repo/back-end/repo!464


j@bt ~/Documents/trabajo/acme/repo (feature/TAREA) % git log --pretty=%P -n 1 "HASH_NUEVO_2"
HASH_MERGE_FEATURE_2


Tanto en git log como con git log --pretty=%P -n 1, se ve que han cambiado los padres del commit «feat: [TAREA] COMENTARIO_2«, y consecuentemente los descendientes HASH_NUEVO_2 y HASH_NUEVO_1 (anteriormente HASH_ANTIGUO_2 y HASH_ANTIGUO_1).

Como siempre, si la rama está publicada es mejor mergear. Si en cualquier caso se hiciese un push force, es mejor avisar al resto del equipo.