Fusionner

Fusionner, c'est faire converger deux lignes de développement. Git distingue deux situations, et sait laquelle s'applique.

L'avance rapide

Si la branche cible n'a pas bougé depuis que l'autre en est partie, il n'y a rien à réconcilier : Git se contente d'avancer le pointeur.

avant :   A───B───C (main)
                   \
                    D───E (correctif)

après :   A───B───C───D───E (main, correctif)

Aucun commit n'est créé. L'historique reste linéaire — et ne garde aucune trace du fait qu'une branche a existé.

Le commit de fusion

Si les deux branches ont divergé, Git crée un commit qui a deux parents.

A───B───C───F (main)
     \     /
      D───E (fonction)

F est le commit de fusion : il enregistre que ces deux histoires n'en font plus qu'une. C'est le seul type de commit à plusieurs parents, et c'est ce qui rend l'historique lisible comme un graphe.

git merge --no-ff force ce commit même quand une avance rapide serait possible : certaines équipes le préfèrent, pour que chaque fonctionnalité reste identifiable dans l'historique.

Un conflit n'est pas une erreur

Git s'arrête quand deux branches modifient les mêmes lignes du même fichier : il ne peut pas décider à ta place.

<<<<<<< HEAD
const TIMEOUT = 30;
=======
const TIMEOUT = 60;
>>>>>>> fonction

Entre <<<<<<< et ======= : ta version, celle de la branche courante. Entre ======= et >>>>>>> : celle qui arrive. Résoudre consiste à écrire le contenu final — qui peut être l'une, l'autre, ou aucune des deux — puis à supprimer les trois marqueurs, git add le fichier et conclure par git commit.

Fusion ou rebase

Le choix est une convention d'équipe, pas une question technique. Il est traité en détail dans Réécrire l'histoire et, du point de vue des stratégies de branches, dans Architectures de pipelines.