Comment fonctionne la fusion dans Git ?

Question

Accepted Answer

**Merging** combine les modifications d'une branche à une autre — typiquement pour réintégrer une branche de fonctionnalité complétée dans la branche principale. Git gère la plupart des fusions automatiquement, mais comprendre les types de fusion et les **conflits** est important. ## Fusion basique ```bash git switch main # be on the branch you want to merge INTO git merge feature-x # merge feature-x's changes into main ``` Vous basculez vers la branche **cible** (celle qui reçoit les modifications) et fusionnez la branche **source** dans celle-ci. ## Fast-forward vs commit de fusion ```text FAST-FORWARD merge → if main hasn't changed since the branch was created, Git just MOVES main's pointer forward to the branch's latest commit (no merge commit, linear) MERGE COMMIT (three-way merge) → if BOTH branches have new commits, Git creates a new "merge commit" combining them (has two parents) → preserves that a merge happened → git merge --no-ff forces a merge commit even when fast-forward is possible ``` Git fast-forward quand c'est possible (en avançant simplement le pointeur) ou crée un **commit de fusion** (avec deux parents) quand les deux branches ont divergé. ## Conflits de fusion ```text A CONFLICT happens when both branches changed the SAME lines differently — Git can't auto-decide which to keep, so it asks YOU to resolve: ``` ```text <<<<<<< HEAD the version from the current branch (main) ======= the version from the branch being merged (feature-x) >>>>>>> feature-x ``` ```bash # resolve: edit the file to the desired result, remove the markers, then: git add # mark the conflict resolved git commit # complete the merge # git merge --abort # or cancel the merge entirely ``` Les **conflits** se produisent quand les deux branches modifient les mêmes lignes — Git les marque et vous choisissez manuellement le résultat correct, puis vous indexez et validez. ## Pourquoi c'est important Comprendre la fusion est essentiel car combiner les modifications de branches est une partie fondamentale et constante des workflows Git collaboratifs, donc savoir comment cela fonctionne (y compris les conflits) est une connaissance nécessaire au quotidien. **Merging** est comment le travail complété (typiquement les branches de fonctionnalité) s'intègre à nouveau dans la branche principale — l'acte routinier de rassembler les modifications qui se produit continuellement dans le développement en équipe. Comprendre la différence entre une **fusion fast-forward** (Git avançant simplement le pointeur quand la cible n'a pas divergé, gardant l'historique linéaire) et un **commit de fusion** (une fusion à trois voies créant un nouveau commit avec deux parents quand les deux branches ont de nouveaux commits, enregistrant qu'une fusion s'est produite) clarifie comment Git intègre les modifications et à quoi ressemble l'historique résultant. Most importantly, understanding **merge conflicts** — which occur when both branches change the same lines differently, so Git can't automatically decide and asks you to resolve — is crucial practical knowledge: conflicts are a normal, inevitable part of collaboration, and knowing how to recognize the conflict markers (`<<<<<<<`, `=======`, `>>>>>>>`), edit the file to the correct result, and complete the merge (stage and commit) is an essential skill that's often a source of anxiety for those who don't understand it. Since integrating branch changes via merging is fundamental and constant in collaborative development, and since understanding merge types and especially resolving conflicts is necessary to combine work correctly (a routine, unavoidable task), understanding how merging works — basic merges, fast-forward vs merge commits, and conflict resolution — is essential, frequently-applied Git knowledge, a core skill for collaboration where conflict resolution in particular is a practical necessity every developer must handle confidently.