Merge — ce que c'est, comment fonctionne merge et les stratégies de fusion

Qu'est-ce que merge dans Git

Merge est la commande git merge qui combine les modifications de la branche spécifiée dans la branche courante. Git trouve l'ancêtre commun (commit de base), calcule le diff de chaque branche par rapport à l'ancêtre et crée un commit de merge contenant l'ensemble combiné des modifications. Le résultat est que la branche cible reçoit toutes les modifications de la branche fusionnée.

Syntaxe : étant sur la branche cible (ex. main), exécutez git merge feature. Git crée automatiquement un commit de merge s'il n'y a pas de conflits. Le message par défaut du commit de merge est : « Merge branch 'feature' into main ». Vous pouvez modifier le message avec le drapeau -m ou l'éditer dans l'éditeur ouvert.

Merge est une opération non destructive. Contrairement à rebase, merge ne touche pas aux commits existants : ils conservent les mêmes hachages, auteurs et dates. Cela fait de merge la seule façon sûre de fusionner des branches sur lesquelles plusieurs développeurs travaillent simultanément. Si quelque chose ne va pas, merge peut être annulé avec git merge --abort.

# Basculer vers la branche cible
git checkout main

# Fusionner la branche de fonctionnalité
git merge feature

# Résultat — commit de merge avec deux parents
git log --oneline --graph

# Merge avec message personnalisé
git merge feature -m "feat: integrate authentication module"

Types de merge : regular, squash, fast-forward

Git prend en charge trois modes de fusion qui sont choisis en fonction du résultat souhaité. Le merge régulier (par défaut) crée un commit de merge. Le squash merge combine tous les commits de la branche de fonctionnalité en un seul. Fast-forward déplace le pointeur de branche sans créer de commit, si possible. Le choix du mode dépend du flux de travail de l'équipe et des règles d'historique.

Merge régulier (--no-ff) — crée un commit de merge même si la fusion pourrait être réalisée en fast-forward. Recommandé pour la branche main : un commit de merge marque clairement le point d'intégration de la fonctionnalité et permet de revenir facilement sur toutes les modifications de la branche de fonctionnalité avec un seul revert du commit de merge. GitHub utilise ce mode par défaut lors de la fusion de PR via le bouton Merge.

Squash merge (--squash) — rassemble tous les commits de la branche de fonctionnalité en un seul commit dans la branche cible. Utile lorsque l'historique provisoire de la branche de fonctionnalité ne doit pas polluer main. Inconvénient : le lien avec les commits d'origine est perdu — on ne peut pas voir comment la fonctionnalité a été développée étape par étape. GitHub utilise ce mode lors de la sélection de « Squash and merge » dans un PR.

Fast-forward (--ff) — si la branche cible n'a pas de nouveaux commits depuis la divergence de la branche de fonctionnalité, Git déplace simplement le pointeur vers l'avant sans créer de commit de merge. L'historique reste linéaire. Le drapeau --no-ff force un commit de merge, tandis que --ff-only générera une erreur si fast-forward n'est pas possible.

# Forcer le commit de merge (recommandé pour main)
git merge --no-ff feature

# Squash merge — tous les commits en un seul
git merge --squash feature
git commit -m "feat: add authentication"

# Fast-forward uniquement si possible
git merge --ff-only feature

# Abandonner le merge conflictuel
git merge --abort

Stratégies de fusion Git

Les stratégies de fusion déterminent l'algorithme que Git utilise pour combiner les modifications. Chaque stratégie convient à différents scénarios. Git sélectionne automatiquement la stratégie appropriée, mais les développeurs peuvent la spécifier explicitement avec le drapeau --strategy. Comprendre les stratégies aide à prédire le comportement de Git lors de fusions complexes.

Recursive — la stratégie par défaut pour fusionner deux branches. Git trouve l'ancêtre commun, calcule les modifications dans chaque branche et les fusionne. Si un ancêtre commun est trouvé, recursive gère correctement les renommages et les ajouts de fichiers. Lors de conflits, recursive peut utiliser des options supplémentaires : ours (choisir automatiquement notre version) et theirs (choisir leur version).

Octopus — pour fusionner plus de deux branches simultanément : git merge feature1 feature2 feature3. Octopus ne prend pas en charge la résolution de conflits — tous les conflits doivent être résolus avant d'invoquer la commande. Il est rarement utilisé, principalement pour fusionner plusieurs branches indépendantes qui ne sont garanties pas en conflit (ex. différents modules).

Ours — une stratégie spéciale qui ignore complètement les modifications de la branche fusionnée et conserve le contenu actuel de la branche cible. Un commit de merge est créé, mais le contenu reste inchangé. Utile lorsque vous devez enregistrer dans l'historique le fait de la fusion mais refuser en pratique toutes les modifications de l'autre branche.

Résolution des conflits de merge

Le conflit de merge survient lorsque les mêmes lignes d'un fichier ont été modifiées différemment dans les deux branches. Git ne peut pas déterminer automatiquement quelle version est correcte et met le merge en pause. Un conflit peut également survenir lorsqu'un fichier est renommé dans une branche et modifié dans une autre, ou lorsque le même fichier est simultanément supprimé et modifié.

Processus de résolution : Git marque les fichiers en conflit avec des marqueurs. Le fichier affiche des sections avec <<<<<<< HEAD (notre version), ======= (séparateur) et >>>>>>> feature (leur version). Le développeur édite manuellement la section en conflit, sélectionne les lignes souhaitées des deux versions, supprime les marqueurs, enregistre le fichier et l'ajoute à l'index avec git add.

Pour la résolution visuelle des conflits, Git prend en charge mergetool — un outil de comparaison externe. Les mergetools populaires : Meld, KDiff3, Beyond Compare, VS Code (éditeur de conflits intégré). Mergetool affiche trois panneaux : notre version, leur version et le résultat. Le développeur sélectionne visuellement les blocs de code à inclure dans le fichier final.

# Démarrer le merge et détecter le conflit
git merge feature
# CONFLIT (contenu) : Conflit de merge dans src/main.swift

# Vérifier les fichiers en conflit
git status

# Ouvrir mergetool visuel
git mergetool

# Après résolution — add et commit
git add src/main.swift
git commit

# Abandonner le merge
git merge --abort

Quand choisir merge plutôt que rebase

Merge est préférable à rebase dans plusieurs situations clés. Premièrement : lors du travail avec des branches publiques accessibles à d'autres développeurs. Merge ne réécrit pas l'historique, donc les collègues peuvent se synchroniser en toute sécurité. Faire un rebase sur une branche publique crée un historique divergent et cause des conflits pour tous ceux qui ont déjà les anciens commits.

Deuxième situation : lors de la finalisation d'une branche de fonctionnalité. La plupart des équipes préfèrent merge (avec le drapeau --no-ff) dans main pour enregistrer le moment d'intégration de la fonctionnalité. Cela simplifie la navigation dans l'historique et permet de revenir facilement sur une fonctionnalité entière avec un seul git revert du commit de merge. GitHub Flow propose par défaut trois options de merge : merge simple, squash merge et rebase merge.

Troisième situation : lors du travail avec une pull request révisée. GitHub et GitLab proposent un bouton de merge avec différentes options. Merge (Create a merge commit) — historique complet avec un commit de merge. Squash and merge — historique propre sans détails de développement. Rebase and merge — historique linéaire sans commit de merge, mais avec réécriture de commits. Le choix dépend des règles de l'équipe.

• Branches publiques (main, develop) — seulement merge, jamais rebase.
• Finalisation de PR — merge avec --no-ff pour marquer le point d'intégration.
• Branches avec des commits d'autrui — merge ne réécrit pas le travail des autres.
• Avant la release — merge est plus sûr car il comporte moins de risques.
• Branche partagée — si plusieurs développeurs travaillent sur une branche, merge est obligatoire.

Meilleures pratiques pour la fusion de branches

Première règle : être toujours sur la version la plus récente de la branche cible avant de fusionner. Exécutez git checkout main && git pull avant de fusionner la branche de fonctionnalité. Cela minimise les conflits et garantit que le commit de merge contient toutes les dernières modifications. Si la branche cible a considérablement avancé, exécutez d'abord git merge main dans la branche de fonctionnalité pour résoudre les conflits dans son contexte.

Deuxième règle : tester le code après le merge. La fusion peut modifier le comportement même sans conflits. Le pipeline CI/CD doit exécuter des tests sur le commit de merge avant l'envoi en production. Certaines équipes utilisent des portes de merge (merge gates) — des vérifications obligatoires qui bloquent le merge jusqu'à leur réussite.

Troisième règle : documenter les commits de merge. Le message standard « Merge branch 'feature' into main » est peu utile. Il est recommandé d'ajouter une description de ce qui a été fusionné : « Merge authentication module: login, registration, password recovery ». Cela simplifie l'analyse de l'historique et la recherche de régressions. Dans les grands projets, les commits de merge sont générés automatiquement à partir du titre du PR.

• À jour — avant de fusionner, assurez-vous que la branche cible est à jour (git pull).
• Tests — le CI/CD doit exécuter des tests sur le commit de merge résultant.
• Messages descriptifs — spécifiez dans le commit de merge quelle fonctionnalité a été fusionnée.
• Fréquence — fusionnez les branches de fonctionnalité dès que possible et aussi souvent que possible (une semaine maximum).
• Annulation — git revert d'un commit de merge annule l'ensemble de la fonctionnalité.