Synopsis
git merge [--no-ff] [--squash] [--abort] [-s <strategy>] [<branch>]
Description
The git merge command integrates changes from one branch into another. By default it produces a "true merge" commit with two parents, preserving the topology of both histories. If the target branch is a strict ancestor of the source, Git fast-forwards by simply moving the branch pointer; pass --no-ff to always record a merge commit.
When the same lines are changed on both sides, Git pauses with a conflict marker. You resolve manually, then git add the files and run git commit (or git merge --continue). To bail out of an in-progress merge, use git merge --abort.
Dans l'usage quotidien, git merge s'intègre étroitement avec les alias de shell, les plugins d'éditeur et l'intégration continue. Les utilisateurs avancés ajoutent souvent des alias combinant les flags qu'ils passent toujours, ou enveloppent la commande dans des scripts qui appliquent les conventions d'équipe. Le formatage de la sortie peut être personnalisé via la configuration Git — pretty formats, schémas de couleurs et comportement du pager sont tous ajustables. Quand quelque chose tourne mal, la première étape de diagnostic est généralement de relancer la commande avec GIT_TRACE=1 dans l'environnement, ce qui révèle les appels de plomberie sous-jacents. Pour les situations inhabituelles, la sortie --help (git merge --help) ouvre la page de manuel complète avec les détails de chaque option, y compris celles rarement utilisées dans les workflows ordinaires mais essentielles pour le débogage ou le scripting à grande échelle.
Comprendre comment git merge interagit avec le reste du modèle de données de Git — la base d'objets, l'index, les refs et l'arborescence de travail — est rentable. Chaque commande opère sur un sous-ensemble de ces pièces, et savoir laquelle elle touche aide à prédire les résultats et récupérer après les erreurs. Lire la documentation officielle de Git en parallèle de la pratique sur un dépôt jetable est la façon la plus rapide d'intérioriser les subtilités. La plupart des problèmes de production avec Git proviennent de l'une de trois causes : comportement par défaut surprenant, opérations réseau partielles, ou réécriture d'historique déjà partagé. Un modèle mental fonctionnel des effets de bord de git merge aide à éviter les trois.
Options courantes
| Option | Description |
|---|---|
--no-ff | Toujours créer un merge commit, même si fast-forward est possible. |
--ff-only | Refuser le merge sauf si fast-forward est possible. |
--squash | Combiner l'historique mergé en un seul commit sur la branche cible. |
--abort | Abandonner un merge en cours. |
--continue | Reprendre un merge après résolution des conflits. |
-s <strategy> | Choisir la stratégie de merge (ort, recursive, resolve, octopus). |
-X <option> | Passer une option spécifique à la stratégie (par ex. ours, theirs). |
--no-commit | Stager le résultat du merge sans commiter. |
Exemples
git merge feature/login
# Merger la branche feature dans la branche courante
git merge --no-ff release/1.2
# Toujours faire un merge commit (préserve la topologie)
git merge --abort
# Annuler un merge après l'apparition de conflits
git merge -X theirs hotfix
# Auto-résoudre les conflits en préférant "their" side
Erreurs fréquentes
Resolving conflicts in a hurry and forgetting to remove conflict markers (<<<<<<<) leaves broken code committed. Always run a build or tests after resolving. Another pitfall is fast-forwarding silently when you wanted a merge commit for traceability — use --no-ff. Finally, --squash does NOT create a merge commit, so the source branch isn't recorded as a parent.
Commandes liées
git rebase, git mergetool, git pull, git cherry-pick