Git - Différences entre merge et rebase

Dernière modification: 2018-08-27 09:56

Revenons aux bases: Git.

Ce puissant outil de gestion de versions est largement sous-estimé par les nouveaux venus car « Oh, wow, c'est super dur de comprendre quelle est la différence entre git pull origin main et git merge origin/main, et puis de toute façon c'est quoi ce "/" au milieu ? »

Oui, je trolle un peu, mais en fait, il y a quelque chose de génial que nous pouvons faire et qui est très simple quand on sait ce que c'est : rebase.

Commençons avec ça :

* 33facc8  (main) Commit 3
|
| * 3b36f32  (second_branch) Commit détaché
| |
|/
* 29af11f  Commit 2
|
* 1439f8e  Commit 1

Nous travaillerons sur la branche second_branch, qui est créée sur la base d'une version précédente de la branche main. La branche second_branch a un commit de plus que main. Mais, entre temps, quelqu'un s'est mis à travailler sur main et a rajouté des commits.

Nos branches divergent.

Problème : j'ai besoin des modifications de Commit 3 pour travailler sur ma branche (ou alors mon équipe veut que je garde toujours mon code à jour avec main).

Deux possibilités ici :

Utiliser merge (ou pull pour les paresseux, puisque c'est juste un alias de fetch + merge).
Utiliser rebase.

Rappel : nous travaillons sur second_branch. Cela signifie que nous avons préalablement exécuté la commande git checkout second_branch.

Résultat d'un `git merge main`

*   63c6403  (main) Merge "second_branch" in "main"
|\
| |
* | 33facc8 Commit 3
| |
| * 3b36f32  (second_branch) Commit détaché
| |
|/
* 29af11f  Commit 2
|
* 1439f8e  Commit 1

Comme les branches divergent, nous ne pouvons pas fast-forward (un peu de documentation sur "fast-forward") le processus de merge, donc Git crée ce que nous appelons un commit de merge pour appliquer toutes les modifications de main dans second_branch.

Du coup, nous avons un graphe Git un peu laid.

MAIS, ça reste cohérent avec tous les commits car ils ne changent pas.

Remarque : Ce qui est cool c'est que si vous supprimez uniquement le commit de fusion (numéro 63c6403 dans notre cas) de l'arborescence (avec un rebase -i ou un reset), alors tous les commits de la branche fusionnée sont également détachés de la branche
Ça permet un rollback très facile lorsque vous devez fusionner des tonnes de commits d'une branche et que vous devez rollback dans l'urgence : supprimez simplement le commit de fusion et c'est fait.

Résultat d'un `git rebase main`

* a018520  (HEAD -> second_branch) Commit détaché
|
* 33facc8  (main) Commit 3
|
* 29af11f  Commit 2
|
* 1439f8e  Commit 1

Le HEAD précédent (pointeur vers le dernier commit de la branche actuellement sélectionnée) de ma second_branch était "Commit 2", et en exécutant git rebase, je veux que ce HEAD soit le même que la branche main, donc que les branches aient la même base, et ensuite je veux ajouter tous les commits de second_branch qui n'étaient pas dans main à la base.

Cela crée un très joli arbre Git bien linéaire.

MAIS, l'arborescence change, car le hash de Commit détaché (dans la second_branch) était 3b36f32 au début, et a changé pour a018520 après le rebase. En gros, si quelqu'un avait commencé à travailler sur second_branch sans committer ses changements, il lui sera difficile de récupérer la nouvelle version de second_branch car son arbre a complètement changé. C'est quand même possible, mais pas simple pour autant.

C'est un peu complexe, j'avoue, mais en réalité, il s'agit de changer l'ancien "commit de base" de cette branche vers la "nouvelle" base.

Si vous avez besoin d'une meilleure représentation, vous pouvez jeter un oeil sur google images pour quelques graphiques de ce que produit un "rebase". C'est joli (oui, j'aime les graphes).

Résumé

`git merge {branch}`

Applique les modifications de la branche {branch} à la branche courante, et si les branches divergent (ou que l'option --no-ff est spécifiée), Git créera un nouveau "commit de merge" indiquant que les deux branches ont été fusionnées.

`git rebase {branch}`

Réécrit l'historique actuel de la branche. Dans un premier temps, il garde tous les "nouveaux commits" de la branche courante (en commençant par HEAD) en mémoire, puis applique tous les commits "manquants" de la branche {branch} (qui devrait de toute façon fast-forward), et enfin applique les modifications de la branche courante qui sont en mémoire une par une, jusqu'à ce que chaque conflit (s'il y en a) soit résolu, et change les hash des nouveaux commits.

Et rebase n'est qu'un seul des nombreux composant de Git.

Regardez aussi les commandes for-each-ref ou log, vous pouvez faire des trucs géniaux avec !