Merge vs rebase

1 - Merge

git merge ma_branche master
Cette commande fait une fusion à 3 branches, il fusionne donc les 2 branches sur une troisième. La résultante de cette troisième branche sera un commit de merge qui relie les 2 branches.

Cette méthode ajoute donc un commit de merge mais les autres commits n'ont pas été impactés et un simple remove du dernier commit vous permez de revenir à l'état précédent. Cette méthode est donc non destructeur.

2 - Rebase

git checkout ma_branche
git rebase master

Pour faire un rebase, git recherche le premier ancêtre commun et réapplique chacun des commits de notre branche (ma_branche) sur l'extrémité de la branche cible (master). Chacun des commits réappliqués est modifié ( résultant de la fusion des 2 branches).

3 - Comparaison

Il faut préconiser un rebase qui permet d'avoir un historique et un graphe propre des commits, plutot qu'un merge qui va vous ajouter des commits de merge en cas de conflit qui bien souvent n'amènera rien et polluera l'historique le graphe

Mais il faut aussi avouer qu'il faut maitrîser et comprendre ce que l'on fait pour ne pas faire de bêtises irréparables.

Pour bien visualiser ce qui est fait voici la différence entre la merge et un rebase au niveau de l'historique et du graphe.

image.png

Si vous êtes plusieurs à travailler sur une même branche et ne pas faire de merge à chaque fois que vous voulez récupérer le travail d'un collègue, il existe la commande suivante pour intégrer le code comme un rebase 

git pull --rebase
Le but de la gestion de conf est de comprendre ce qui a été fait en lisant les commentaires des commits pour ensuite aller voir le contenu exact du commit, afin de réupérer du code, un commit, etc. Avoir un historique de tout ce qui a été fait, y compris les ereurs n'est pas constructif pour le produit, certes c'est le véritable historique de ce qui s'est passé mais ce qui nous intéresse c'est historique en terme de code (bug, fix, evolution du code). Je vais reprendre l'image utilisée dans le lien ci-dessous, ce qui nous intéresse c'est l'historique des versions final d'un livre et non la liste des brouillons, des changements de des corrections orthographiques, etc pour arriver à une version final livre Il est bien sûr parfois plus intéressant et utile de faire des merge, souvent sur des branches partagés. Pour nous, cela se limite à la branche master où le rebase est à proscrire. Pour les autres branches tant qu'on peut rendre un historique plus clair il est préférable de faire des rebase ( le merge-request doit aussi vérifier que les commits soient clair et précis) .

3 - Pour aller plus loin

https://git-scm.com/book/fr/v2/Les-branches-avec-Git-Rebaser-Rebasing