Merge — qu'est-ce que c'est, types de fusion et mécanisme de fonctionnement

Qu'est-ce que Merge ?

Merge (fusion) est une opération fondamentale dans Git qui combine les modifications d'une branche (source) dans une autre (cible). À la suite de la fusion, la branche cible reçoit tous les commits de la branche source qui n'étaient pas encore dans celle-ci. Selon la situation, Git peut effectuer le merge de trois manières différentes.

La principale valeur du merge est la préservation de l'historique : le merge commit enregistre le fait de la fusion des branches, conservant des informations sur quand et quelles branches ont été fusionnées. Cela facilite l'audit des modifications, la recherche de régressions et la compréhension de la chronologie du développement. Dans les grands projets, le merge commit est la méthode standard d'intégration de code.

Selon GitLab Flow, les merge commits sont utilisés dans 73 % des équipes travaillant avec Git. Les approches alternatives (rebase, squash) sont préférées par les équipes axées sur un historique linéaire. Le choix de la stratégie dépend de la taille de l'équipe, de la fréquence des versions et des conventions acceptées dans le projet.

Quand Merge se produit

Merge est nécessaire lorsqu'un développeur a terminé de travailler sur une fonctionnalité et souhaite l'intégrer dans develop ou main. Un scénario typique : un développeur a créé une branche de fonctionnalité à partir de develop, a travaillé dessus pendant plusieurs jours, et pendant ce temps, de nouveaux commits d'autres membres de l'équipe sont apparus dans develop. Avant la fusion, les modifications doivent être combinées — et c'est à cela que sert le merge.

Sans merge, il est impossible de travailler collaborativement sur un seul code dans Git. Chaque fois que deux développeurs apportent simultanément des modifications à une même base de code, leurs branches divergent. Le merge est le seul moyen de réunir ces modifications sans perte de données.

Types de fusion dans Git

Git prend en charge trois types de merge, chacun conçu pour son propre scénario. Le choix du type de fusion affecte l'historique des commits, la facilité de retour en arrière et la lisibilité du journal.

Fast-forward merge

Fast-forward se produit lorsque la branche cible n'a pas eu de nouveaux commits depuis la création de la branche source. Dans ce cas, Git déplace simplement le pointeur de la branche cible vers l'avant, jusqu'au dernier commit de la branche source. L'historique reste linéaire, sans merge commit.

# Fast-forward merge : develop n'a pas changé depuis la création de feature
git checkout develop
git merge feature/new-login

# Résultat : le pointeur develop s'est déplacé à la fin de feature
# Aucun merge commit n'a été créé

Fast-forward est pratique pour les branches de courte durée où un développeur a travaillé seul. Mais cette approche a un inconvénient : l'information que la branche a existé est perdue — tous les commits semblent avoir été faits directement dans develop.

Three-way merge

Three-way merge est exécuté lorsque les deux branches ont de nouveaux commits après le point de divergence. Git crée un merge commit séparé avec deux parents, qui enregistre le fait de la fusion des branches. Cette approche est recommandée pour les branches de fonctionnalité dans le développement en équipe.

# Three-way merge forcé avec le drapeau --no-ff
git checkout develop
git merge --no-ff feature/new-login

# Un merge commit a été créé avec le message par défaut
# Vous pouvez définir votre propre message via -m
git merge --no-ff feature/new-login -m "Merge feature/new-login into develop"

Le drapeau --no-ff garantit la création d'un merge commit, même si le fast-forward est possible. C'est une bonne pratique pour préserver les informations de branchement dans un projet.

Squash merge

Squash merge compresse tous les commits de la branche source en un seul et l'applique à la cible. L'historique de la fonctionnalité est perdu — un seul commit avec toutes les modifications aboutit dans la branche. C'est pratique lorsque les commits détaillés dans une branche de fonctionnalité n'apportent pas de valeur à l'historique global.

# Squash merge : tous les commits de feature sont compressés en un
git checkout develop
git merge --squash feature/experimental
git commit -m "feat: experimental login flow (squashed)"

Squash convient aux brouillons, aux branches expérimentales et aux situations où il est important de maintenir un historique propre. L'inconvénient est que le lien avec les commits originaux est perdu, ce qui complique le retour arrière sur des modifications individuelles.

Stratégies Ours et Theirs

Ours et Theirs sont deux stratégies spéciales de merge dans Git. Ours ignore complètement les modifications de la branche source, ne conservant que ce qui est dans la cible. Theirs, au contraire, accepte la version de la branche source en cas de conflit. Ces stratégies sont utiles lors de la fusion de grandes quantités de code lorsque l'on sait à l'avance quelle version doit prévaloir.

Comment fonctionne Merge

Le mécanisme de merge dans Git est basé sur la comparaison de trois points : l'ancêtre commun (merge base), l'état de la branche source et l'état de la branche cible. Git trouve le merge base — le dernier commit commun aux deux branches — et calcule quelles modifications sont survenues dans chaque branche après la divergence.

• Étape 1 — Git détermine le merge base : le dernier commit présent dans les deux branches
• Étape 2 — Git construit deux diff : du merge base à source et du merge base à target
• Étape 3 — Git tente d'appliquer les deux ensembles de modifications au merge base
• Étape 4 — Si les modifications ne sont pas en conflit — le merge se termine automatiquement
• Étape 5 — S'il y a un conflit — Git s'arrête et demande une résolution

Git utilise un algorithme de fusion à trois voies qui prend en compte non seulement les deux versions du fichier comparées, mais aussi leur ancêtre commun. Grâce à cela, Git peut résoudre automatiquement les situations où les modifications dans une branche n'affectent pas les zones modifiées de l'autre — même si les deux fichiers ont été modifiés.

Exemple de fonctionnement du merge

Considérons un scénario : deux développeurs travaillent sur des fichiers différents dans une même branche de fonctionnalité. Le premier a modifié LoginActivity.kt, le second a modifié ProfileFragment.kt. Lorsqu'ils fusionnent leurs modifications, Git voit que les modifications ont affecté des fichiers différents et effectue le merge automatiquement, sans intervention humaine.

Si les deux développeurs ont modifié LoginActivity.kt, mais dans des méthodes différentes — Git s'en chargera également automatiquement, fusionnant les modifications ligne par ligne. Un conflit ne survient que si les deux ont modifié les mêmes lignes ou si l'un a supprimé du code que l'autre a modifié.

Résolution des conflits dans Merge

Un conflit de merge survient lorsque Git ne peut pas fusionner automatiquement les modifications parce que les deux branches ont modifié les mêmes lignes différemment. Dans ce cas, Git marque les zones conflictuelles dans les fichiers et attend la résolution manuelle du développeur.

Les zones conflictuelles sont marquées avec des marqueurs spéciaux : <<<<<<< HEAD montre le code de la branche cible, ======= est le séparateur, >>>>>>> source-branch montre le code de la branche source. Le développeur doit choisir manuellement quelle version conserver ou les combiner.

# 1. Lancer le merge et voir le conflit
git merge feature/new-login
# Sortie : CONFLICT (content) : Merge conflict in LoginActivity.kt

# 2. Voir la liste des fichiers en conflit
git status
# both modified : src/ui/login/LoginActivity.kt

# 3. Résoudre le conflit : modifier le fichier, supprimer les marqueurs
# 4. Ajouter le fichier résolu et terminer le merge
git add src/ui/login/LoginActivity.kt
git merge --continue
# ou : git commit (sans --continue)

Il existe des outils pour résoudre les conflits : git mergetool ouvre un outil de fusion visuelle (Meld, Beyond Compare, VS Code). De nombreux développeurs préfèrent résoudre les conflits dans l'IDE — IntelliJ IDEA et Android Studio fournissent un outil intégré avec une comparaison à trois volets qui simplifie grandement ce processus.

Conseils pour résoudre les conflits : comprenez toujours ce que fait chaque côté du conflit, ne supprimez pas le code d'autrui sans comprendre sa logique, et si le conflit est trop complexe — impliquez les auteurs des deux branches dans une résolution conjointe.

Merge vs Rebase : quand choisir quoi

Le choix entre Merge et Rebase est l'une des décisions architecturales les plus courantes dans Git. Les deux approches combinent les modifications, mais le font différemment : merge préserve l'historique de branchement, rebase réécrit l'historique en le rendant linéaire.

• Merge — préserve le contexte : on peut voir quand et à partir de quelle branche une fusion a été faite. Meilleur pour les branches publiques (develop, main) et le travail d'équipe
• Rebase — crée un historique linéaire propre sans merge commits supplémentaires. Meilleur pour les branches de fonctionnalité personnelles avant la révision
• Règle : ne faites jamais de rebase sur des branches publiques que d'autres développeurs utilisent

De nombreuses équipes utilisent une approche hybride : rebase pour mettre à jour la branche de fonctionnalité avec develop (git rebase develop), puis merge avec le drapeau --no-ff pour enregistrer la fusion. Cela donne un historique propre au sein de la fonctionnalité et des points de fusion informatifs au niveau de develop.