# Résoudre les conflits de merge Git avec l’IA

URL: https://agentvera.dev/fr/blog/resolve-merge-conflicts-with-ai/ · Publié: 2026-10-29

Résoudre les conflits de merge avec l’IA sans perdre de travail : zdiff3, un prompt pour votre agent, tests avant git add, rerere, rebase ou merge, et prévention.

**En bref:**

- Passez d’abord merge.conflictStyle à zdiff3 : le conflit affiche alors l’ancêtre commun, et vous comme l’agent voyez ce que chaque côté a réellement changé.
- Donnez à l’agent l’intention des deux branches, les fichiers en conflit et des règles strictes : garder les deux changements, ne toucher qu’à ces fichiers, aucun marqueur restant, ne pas modifier les tests.
- Vérifiez avant git add : git diff --check pour les marqueurs oubliés, puis vérification de types, tests et build, et enfin relisez vous-même le diff résolu.
- La plupart des conflits s’évitent : petites tâches, un propriétaire par zone de fichiers, rebase fréquent sur main et une file de fusion qui teste chaque branche sur la dernière pointe.

**Pour résoudre les conflits de merge avec l’IA en toute sécurité, rendez d’abord le conflit lisible, donnez ensuite à un agent de code l’intention des deux côtés et des règles strictes, et n’acceptez le résultat qu’une fois que Git confirme qu’il ne reste aucun marqueur de conflit et que vos tests passent.** Des agents comme Claude Code et Codex sont vraiment utiles ici : ils lisent les deux versions, l’ancêtre commun et le code environnant plus vite que vous, et savent combiner deux changements au lieu d’en choisir un. Leur défaut typique est tout aussi net : quand l’intention d’un côté n’est pas claire, ils gardent le côté qui compile et abandonnent l’autre sans prévenir.

Ce guide explique pourquoi les conflits apparaissent (et pourquoi les agents en parallèle les rendent plus fréquents), propose un déroulé pas à pas de `git status` à `git merge --continue`, un modèle de prompt, le choix entre rebase et merge, `git rerere`, une vérification avant fusion et la manière d’éviter la plupart des conflits dès le départ. Les commandes Git ont été vérifiées dans la documentation officielle sur git-scm.com, en date d’octobre 2026.

## Pourquoi les conflits de fusion apparaissent

Quand Git fusionne deux branches, il compare chacune à leur ancêtre commun. Les changements dans des zones différentes d’un fichier sont combinés automatiquement. Quand les deux côtés ont modifié **la même zone**, Git ne peut pas choisir : il s’arrête et écrit les deux versions dans le fichier, entre des marqueurs de conflit. C’est un conflit textuel.

Les cas les plus courants :

- **Conflit de contenu :** les deux branches ont modifié les mêmes lignes du même fichier.
- **Modification/suppression :** une branche a modifié un fichier, l’autre l’a supprimé ou déplacé.
- **Fichiers générés :** lockfiles, snapshots, sorties de compilation ou fichiers de traduction que les deux branches ont régénérés.

Il existe aussi un conflit que Git ne voit pas : le **conflit sémantique**. Deux branches touchent des fichiers différents, fusionnent proprement et se cassent pourtant mutuellement, par exemple quand l’une change la signature d’une fonction et que l’autre ajoute un nouvel appel. Seuls des tests sur le résultat fusionné l’attrapent ; l’[article sur la file de fusion](/fr/blog/merge-queue-for-ai-agents/ "File de fusion pour agents IA") en montre un exemple.

### Pourquoi les agents en parallèle multiplient les conflits

Plusieurs agents à la fois, chacun dans son propre [git worktree](/fr/glossary/git-worktree/ "Qu’est-ce qu’un git worktree"), n’écrasent pas les fichiers des autres pendant qu’ils travaillent. Cela n’empêche pas le conflit : cela le repousse au moment de la fusion. Chaque agent travaille sur la base de départ et ne voit jamais ce que les autres ont changé. Certains fichiers attirent les conflits encore et encore :

- tables de routes, configurations d’injection de dépendances et autres registres où chaque fonctionnalité ajoute une ligne,
- fichiers barrel (`index.ts`) et types partagés,
- `package.json` et son lockfile,
- fichiers de traduction, changelogs et fichiers de configuration.

Le zèle des agents n’aide pas non plus : ils reformatent un fichier qu’ils devaient seulement effleurer, renomment un helper « tant qu’ils y sont » ou corrigent un avertissement de lint sans rapport. Chacun de ces gestes élargit la zone modifiée par les deux branches.

## Étape 1 : s’arrêter et regarder avant tout

Quand un merge ou un rebase s’arrête, sachez où vous en êtes avant de demander à qui que ce soit, humain ou agent, de corriger :

```bash
git status                                  # quelle opération, quels fichiers sont "both modified"
git diff --name-only --diff-filter=U        # uniquement les fichiers non fusionnés
```

`--diff-filter=U` sélectionne les chemins non fusionnés, ce qui donne une liste propre à transmettre à l’agent. Gardez aussi les sorties de secours en tête. Si le conflit est plus gros que prévu, rien n’est encore perdu :

```bash
git merge --abort      # revenir à l’état d’avant la fusion
git rebase --abort     # remettre la branche où elle était avant le rebase
```

La documentation de Git recommande de committer ou de mettre de côté (stash) vos changements avant de lancer `git merge`, car `--abort` ne peut pas toujours reconstruire un travail non commité. C’est pareil pour le worktree d’un agent : laissez-le committer avant d’y fusionner quoi que ce soit.

## Étape 2 : passer à zdiff3 pour voir la base

Par défaut, Git n’affiche que les deux côtés :

```text
<<<<<<< HEAD
const timeout = config.timeout ?? 30_000;
=======
const timeout = getTimeout(config);
>>>>>>> feature/retry
```

Impossible de savoir à quoi ressemblait la ligne d’origine, donc ce que chaque côté voulait faire. Passez le style de conflit à `zdiff3` (arrivé avec Git 2.35 ; utilisez `diff3` sur les versions plus anciennes) :

```bash
git config --global merge.conflictStyle zdiff3
```

Le conflit inclut maintenant l’ancêtre commun après un marqueur `|||||||` :

```text
<<<<<<< HEAD
const timeout = config.timeout ?? 30_000;
||||||| base
const timeout = config.timeout;
=======
const timeout = getTimeout(config);
>>>>>>> feature/retry
```

Tout devient lisible : un côté a ajouté une valeur par défaut, l’autre a déplacé la lecture dans une fonction. La bonne résolution garde probablement les deux, par exemple en plaçant la valeur par défaut dans `getTimeout`. D’après la documentation de git-config, `zdiff3` fonctionne comme `diff3` mais sort de la zone de conflit les lignes identiques au début et à la fin, ce qui garde les blocs courts.

Pour une fusion déjà en cours, vous pouvez recréer les marqueurs d’un fichier dans le nouveau style :

```bash
git checkout --conflict=zdiff3 src/http/client.ts
```

C’est encore plus important pour un agent que pour vous. Sans la base, le modèle doit deviner quel côté a changé quoi, et c’est précisément là que commence la perte de données silencieuse.

## Étape 3 : donner à l’agent le contexte nécessaire

Les marqueurs montrent les lignes. L’agent doit aussi savoir **pourquoi** chaque côté les a modifiées. Git peut afficher l’historique des deux côtés pour un fichier :

```bash
git log --merge -p src/http/client.ts   # d’abord les diffs côté HEAD, puis côté MERGE_HEAD
git show :1:src/http/client.ts          # ancêtre commun
git show :2:src/http/client.ts          # HEAD (ours)
git show :3:src/http/client.ts          # MERGE_HEAD (theirs)
```

Ajoutez le contexte humain : la description de la tâche ou de la pull request de chaque branche. Puis utilisez un prompt de ce genre :

```text
Nous sommes au milieu d’un git merge de feature/retry dans main. Ces fichiers
sont en conflit (merge.conflictStyle vaut zdiff3, la base est visible) :
<sortie de git diff --name-only --diff-filter=U>

Intention de main : <une ou deux phrases, ou la description de la PR>
Intention de feature/retry : <une ou deux phrases, ou la description de la PR>

Pour chaque fichier en conflit :
1. Lis les sections ours, base et theirs et indique en une ligne ce que
   chaque côté a changé par rapport à la base.
2. Écris une résolution qui préserve les deux intentions. S’ils se
   contredisent vraiment, ne choisis pas : arrête-toi et pose-moi la question.
3. Ne modifie que les blocs en conflit. Pas de reformatage, de renommage
   ni de correction sans rapport.
4. Ne modifie pas les tests pour qu’ils passent et ne supprime pas de code
   que tu ne comprends pas.
Pour package-lock.json / pnpm-lock.yaml : résous seulement package.json, puis
régénère le lockfile avec le gestionnaire de paquets.
À la fin : aucun marqueur restant, lance la vérification de types et les tests,
et donne-moi un résumé par fichier de ce que tu as gardé de chaque côté.
Ne lance ni git add, ni git commit, ni git merge --continue.
```

La dernière ligne vous laisse la dernière étape. Le résumé par fichier accélère la relecture : vous comparez chaque affirmation au diff au lieu de tout lire à froid.

## Étape 4 : un fichier à la fois, avec des règles claires

Quelques règles font la différence entre une fusion propre et une régression silencieuse :

- **Pas de `--ours` ou `--theirs` global.** `git checkout --ours <chemin>` prend un côté entier du fichier et jette l’autre. Ne l’utilisez que si vous savez qu’un côté doit l’emporter, par exemple pour un fichier généré que vous allez de toute façon régénérer.
- **Attention à l’inversion pendant un rebase.** La documentation de Git précise que pendant `git rebase` et `git pull --rebase`, `--ours` est la branche sur laquelle vous rebasez et `--theirs` votre propre travail réappliqué. Les agents s’y trompent étonnamment souvent : désignez-leur chaque branche par son nom.
- **Régénérer les fichiers générés, pas les fusionner.** Lockfiles, snapshots et sorties de build doivent venir de l’outil qui les produit, une fois les fichiers sources résolus.
- **Une modification/suppression demande une décision.** Si une branche a supprimé un fichier que l’autre a modifié, l’agent doit le signaler et demander, pas le restaurer ou le supprimer de lui-même.
- **Découper les gros conflits.** Si un fichier compte des dizaines de blocs, demandez à l’agent de le résoudre et de l’expliquer par parties, ou prenez du recul et revoyez l’ordre des fusions.

## Étape 5 : vérifier avant de continuer

Un agent qui dit « résolu » formule une affirmation, pas une preuve. Vérifiez :

```bash
git diff --check                 # signale les marqueurs de conflit oubliés (et les erreurs d’espaces)
git diff                         # relire la résolution
pnpm typecheck && pnpm test      # ou la vérification de votre projet
```

`git diff --check` sort avec un code non nul quand les changements introduisent des marqueurs de conflit : un garde-fou peu coûteux à lancer à chaque fois. Sur les versions récentes de Git, `git diff AUTO_MERGE` n’affiche que les changements faits jusqu’ici pour résoudre les conflits textuels, soit exactement ce que l’agent a écrit.

Terminez ensuite l’opération vous-même :

```bash
git add src/http/client.ts
git merge --continue     # ou : git rebase --continue
```

### Ne jamais accepter à l’aveugle : les signaux d’alerte

| Signal d’alerte | Ce que cela signifie en général |
| --- | --- |
| Le changement d’un côté a tout simplement disparu | L’agent a choisi un côté au lieu de les combiner |
| Un test ou une assertion a changé | La résolution a cassé un comportement et le test a été ajusté |
| Des fichiers hors de la liste des conflits ont changé | Dérive de périmètre : reformatages ou « corrections » à relire à part |
| Du code apparaît en double | Les deux côtés ont été gardés tels quels, sans être fusionnés |
| Des marqueurs ou un `=======` égaré dans un fichier non-code | Personne n’a lancé `git diff --check` |

Si vous en voyez un, demandez à l’agent d’expliquer ce bloc ou refaites le fichier à la main. Une revue de code par IA du résultat fusionné est un deuxième regard utile, mais elle ne remplace pas l’exécution des tests.

## Rebase ou merge quand des conflits sont probables

Les deux fonctionnent ; ils échouent différemment.

| | Merge | Rebase |
| --- | --- | --- |
| Où vous résolvez | Une fois, dans le commit de fusion | Commit par commit, à chaque réapplication |
| Le même conflit deux fois | Non | Possible, sur plusieurs commits |
| `--ours` / `--theirs` | Votre branche / l’autre branche | Inversés : la cible / votre propre travail |
| Historique | Garde un commit de fusion | Linéaire, réécrit les commits de la branche |
| Sûr sur une branche partagée | Oui | Seulement si personne ne travaille par-dessus |

Pour des branches d’agent de courte durée que vous êtes seul à utiliser, rebaser souvent sur main est en général l’habitude la plus simple : les conflits apparaissent tôt, quand ils sont encore petits. Pour les branches longues ou partagées, fusionnez. Pendant un rebase, `git rebase --skip` abandonne entièrement le commit en cours ; ne l’utilisez que si vous êtes sûr qu’il est inutile.

## Laisser Git s’en souvenir : rerere

Si vous rebasez la même branche encore et encore, vous résoudrez le même conflit plusieurs fois. `git rerere` (« reuse recorded resolution ») enregistre la façon dont vous avez résolu un conflit et la rejoue quand le même conflit réapparaît :

```bash
git config --global rerere.enabled true
```

Une fois activé, `git merge` et `git commit` l’appellent automatiquement. Commandes utiles :

```bash
git rerere status       # chemins dont la résolution sera enregistrée
git rerere diff         # état actuel de la résolution
git rerere remaining    # conflits que rerere n’a pas pu résoudre
git rerere forget src/http/client.ts   # oublier une résolution mal enregistrée
```

Deux points à connaître. rerere ne touche pas à l’index : vous vérifiez toujours le résultat et faites `git add`, et c’est tant mieux, car une mauvaise résolution est rejouée aussi fidèlement qu’une bonne. Par ailleurs, `git rerere gc` élague les anciens enregistrements : par défaut, ceux non résolus après 15 jours et ceux résolus après 60.

## Vérifier les conflits avant de fusionner

Pas besoin de lancer une fusion pour savoir si elle sera en conflit. Depuis Git 2.38, `git merge-tree --write-tree` effectue la fusion sans toucher à l’arbre de travail ni à l’index :

```bash
git merge-tree --write-tree --name-only main feature/retry
echo $?    # 0 = propre, 1 = conflits
```

Avec `--name-only`, la section des conflits ne liste que les noms de fichiers. La documentation de Git conseille de se fier au code de sortie plutôt qu’à une liste de fichiers vide. C’est une bonne première consigne pour un agent avant qu’il ne touche à quoi que ce soit : « vérifie si feature/retry fusionne proprement dans main et, sinon, liste les fichiers en conflit et ce que chaque côté a changé ».

## Prévention : moins de conflits avec des agents en parallèle

Le conflit le moins cher est celui qui n’arrive jamais :

- **De petites tâches.** Un agent qui modifie cinq fichiers entre moins en conflit qu’un agent qui en modifie cinquante. Découpez les gros chantiers par zone.
- **Un propriétaire par zone.** Décidez quel agent peut toucher au routeur, au schéma, aux types partagés, et écrivez-le dans les instructions de chaque agent.
- **Fusionner ou rebaser souvent.** Une branche qui vit une heure entre rarement en conflit ; une branche qui vit une semaine, presque toujours.
- **Pas de retouches au passage.** Demandez aux agents de ne rien reformater, renommer ou corriger en dehors de leur tâche.
- **Un seul changement de lockfile à la fois.** Laissez une seule branche ajouter des dépendances, ou régénérez le lockfile après chaque fusion.
- **Une file de fusion.** Les branches atterrissent une par une sur la dernière pointe, avec des tests sur le résultat fusionné, si bien que les conflits sémantiques sont eux aussi détectés.

Pour la mise en place des agents dans des dossiers séparés, lisez [Git worktrees pour agents en parallèle](/fr/blog/git-worktree-parallel-agents/ "Git worktrees pour agents en parallèle").

## Ce qu’apporte AgentVera

AgentVera est une application de bureau qui fait tourner côte à côte des CLI d’agents de code comme Claude Code et Codex, avec Git intégré. Ces fonctionnalités s’insèrent dans le déroulé ci-dessus :

- **Worktrees et panneau Git.** Créez un worktree par fonctionnalité et lancez-y un agent ; indexez fichier par fichier, committez, faites fetch, pull et push, et lisez les diffs façon GitHub, unifiés ou côte à côte.
- **Alertes précoces.** Par défaut, AgentVera lance `git fetch` en arrière-plan toutes les 5 minutes. Quand de nouveaux commits arrivent sur votre branche, un bandeau propose un fast-forward en un clic, ou un rebase si les deux côtés ont des commits. Quand deux agents d’un même projet modifient le même fichier, la [coordination des agents](/fr/features/agent-coordination/ "Coordination des agents") vous prévient ; pour des agents dans des worktrees différents, elle signale que la fusion risque d’être en conflit.
- **Propriété des fichiers.** Avec la [propriété des fichiers](/fr/features/file-ownership/ "Propriété des fichiers"), vous attribuez à un agent des chemins ou des globs comme `src/api/**`. Tant qu’il tourne, les agents Claude Code sont arrêtés avant de modifier ces fichiers et invités à demander au propriétaire ; Codex et les autres CLI reçoivent les règles dans leurs instructions.
- **Équipe parallèle.** Une [équipe parallèle](/fr/features/parallel-team/ "Équipe parallèle") (Pro) découpe un travail en parties qui tournent chacune dans leur propre worktree et fusionnent dans une branche d’intégration. Si une fusion entre en conflit ou si la vérification finale échoue, un agent d’intégration prend le relais.
- **File de fusion.** La [file de fusion](/fr/features/merge-queue/ "File de fusion") (Pro) fusionne les branches une par une sur la dernière pointe de la cible. Un agent Claude résout les conflits, la vérification tourne sur le résultat fusionné avec jusqu’à 2 tours de correction, et une branche impossible à corriger est renvoyée. Par défaut, l’atterrissage attend votre validation.

Si vous travaillez seul, sur une branche à la fois, Git tout simple avec `zdiff3` et `rerere` suffit. Ces outils deviennent rentables quand plusieurs agents produisent des branches en même temps.

## Erreurs fréquentes

- **Résoudre sans la base.** Le style de conflit par défaut cache l’état antérieur du code ; activez `zdiff3`.
- **« Corrige les conflits » comme seul prompt.** Sans l’intention de chaque branche, l’agent choisit le côté qui semble le plus complet.
- **Laisser l’agent lancer `git add` et `--continue`.** Gardez la dernière étape pour après `git diff --check` et les tests.
- **Fusionner les lockfiles à la main.** Résolvez le manifeste, puis régénérez.
- **Rebaser une branche partagée.** Tous ceux qui ont construit dessus devront démêler des commits réécrits.

## En résumé

Résoudre les conflits de merge avec l’IA fonctionne quand l’agent voit tout le tableau et que la preuve reste entre vos mains : des marqueurs `zdiff3` qui montrent la base, un prompt qui énonce les deux intentions et interdit les raccourcis, `git diff --check` et la suite de tests avant `git add`, et `rerere` pour les conflits qui reviennent. La prévention fait le reste : petites tâches, propriété des fichiers claire et branches qui atterrissent une à une.

Pour l’essayer avec vos propres agents, [téléchargez AgentVera](/fr/download/ "Télécharger AgentVera").

## Questions fréquentes

**Un agent de code IA peut-il résoudre des conflits de merge Git ?** Oui, et souvent bien, à condition qu’il voie l’ancêtre commun (style zdiff3), sache ce que chaque branche devait faire et dispose d’une suite de tests pour prouver le résultat. Sans cela, il a tendance à garder un côté et à abandonner l’autre sans le dire.

**Qu’est-ce que le style de conflit zdiff3 ?** Une valeur de merge.conflictStyle qui, comme diff3, ajoute une section ||||||| avec le texte d’origine de l’ancêtre commun, mais sort de la zone de conflit les lignes que les deux côtés ont modifiées à l’identique. Git l’a ajouté dans la version 2.35.

**Pourquoi ours et theirs sont-ils inversés pendant un rebase ?** La documentation de Git explique que pendant git rebase et git pull --rebase, --ours désigne la branche sur laquelle vous rebasez et --theirs votre propre travail en cours de réapplication. Rien que pour cela, un --ours ou --theirs global est risqué.

**À quoi sert git rerere ?** Avec rerere.enabled, Git enregistre la façon dont vous avez résolu un conflit et réapplique cette résolution quand le même conflit réapparaît, par exemple lors d’un rebase répété. Il ne touche pas à l’index : vous vérifiez toujours le résultat et faites git add.

**Comment savoir s’il y aura des conflits avant de fusionner ?** Lancez git merge-tree --write-tree --name-only main feature. La commande effectue la fusion sans toucher à l’arbre de travail ni à l’index, sort avec le code 1 en cas de conflit et liste les fichiers concernés. Il faut Git 2.38 ou plus récent.

---

**À propos d’AgentVera.** AgentVera est une app de bureau pour macOS, Windows et Linux, développée par Solviera Teknoloji. Elle exécute 18 agents de code IA (Claude Code, Codex, Gemini CLI, Copilot, Cursor, Antigravity, opencode, Hermes, Qwen Code, Kimi Code, Kiro, Amp, Droid, Goose, Vibe, Crush, Aider, Cline) côte à côte, par projet, dans de vrais terminaux avec les installations et connexions CLI de l’utilisateur. L’offre gratuite inclut des agents illimités. Télécharger: https://agentvera.dev/fr/download/ · Tarifs: https://agentvera.dev/fr/pricing/