Résoudre les conflits Git en sécurité avec Claude Code

Résoudre un conflit Git ne revient pas à supprimer <<<<<<<, ======= et >>>>>>>. Ces marqueurs ne sont que le symptôme. Le vrai travail consiste à préserver l’intention de deux branches qui ont modifié la même zone du produit: une branche peut avoir renforcé l’autorisation, tandis qu’une autre a ajouté un écran, un appel API et des tests.

Claude Code est utile parce qu’il peut lire les fichiers en conflit, inspecter le code voisin, exécuter des commandes Git, mettre à jour des tests et expliquer le diff final. Mais il ne doit pas remplacer le jugement humain. Un prompt vague comme “corrige tous les conflits” peut produire un code qui compile, tout en supprimant une règle métier ou en dupliquant une validation.

La méthode fiable est donc simple: une personne définit la priorité et le périmètre, Claude Code réalise les modifications mécaniques, puis une personne valide le diff, les tests et le comportement. C’est le flux que j’utilise dans les projets ClaudeCodeLab.

Vue d’ensemble

changements de main ou release
        |
        v
Git signale des fichiers non fusionnés
        |
        v
Claude Code résout avec une politique écrite
        |
        v
revue humaine du diff, des tests et du comportement
        |
        v
commit de l'état résolu

Pour l’exécution non interactive, la documentation officielle Claude Code CLI reference décrit claude -p "query". Pour automatiser les contrôles, consultez Claude Code hooks reference et Claude Code settings. Côté Git, Git rerere documente la réutilisation des résolutions enregistrées.

Vérifier l’état avant tout

Avant d’appeler Claude Code, assurez-vous que le commit de résolution ne va pas embarquer des modifications locales sans rapport.

git status --short
git branch --show-current
git diff --name-only --diff-filter=U

La dernière commande liste uniquement les fichiers non résolus. Lisez cette liste vous-même. Si un fichier inattendu apparaît, comprenez d’abord pourquoi il est en conflit.

Ajoutez quatre informations au prompt:

Question	Exemple de règle
Quel côté est prioritaire	Garder les correctifs sécurité de main et la nouvelle UI de feature
Ce qui peut être modifié	Seulement les fichiers non résolus et les tests liés
Fichiers générés	Regénérer lockfiles et code généré, ne pas les fusionner à la main
Critère de fin	Aucun marqueur, git diff --check propre, tests verts, résumé des décisions

Cette politique courte transforme une action difficile à auditer en un plan que l’on peut relire.

Cas 1: fusionner main dans une branche feature

Le cas le plus courant est une branche feature qui a pris du retard et doit intégrer main avant une pull request.

git fetch origin
git merge origin/main

cat > /tmp/claude-conflict-plan.md <<'PROMPT'
Résous les conflits Git merge actuels.

Contexte:
- La branche actuelle est une branche feature.
- Garde les correctifs de sécurité et les changements de types de origin/main.
- Garde le nouvel écran, l'appel API et les tests de la feature.
- Travaille uniquement sur les fichiers listés par git diff --name-only --diff-filter=U.

Tâches:
1. Explique brièvement pourquoi chaque fichier est en conflit.
2. Supprime les conflict markers et intègre les deux intentions.
3. Mets à jour seulement les tests directement liés si nécessaire.
4. Exécute git diff --check.
5. Résume les décisions et les commandes exécutées.

Ne fais pas:
- Refactoring sans rapport.
- Abandon silencieux d'un côté.
- Édition manuelle de package-lock.json.
PROMPT

claude -p "$(cat /tmp/claude-conflict-plan.md)"
git diff --check
npm test

La précision du périmètre compte plus que la formulation exacte. Priorité, fichiers autorisés, politique des générés et critère de fin rendent le résultat vérifiable.

Une erreur réelle: main ajoutait une vérification d’autorisation plus stricte et la branche feature ajoutait une nouvelle branche d’interface. Avec un prompt “garde les deux”, l’UI restait visible mais l’API renvoyait toujours 403. Depuis, je précise que les changements de sécurité doivent survivre et que la cohérence UI/API doit être vérifiée.

Cas 2: résoudre un rebase étape par étape

Les conflits pendant git rebase sont plus sensibles qu’un merge classique. Git rejoue les commits un par un, et ours / theirs peuvent être trompeurs pendant un rebase. Évitez donc git checkout --ours sans inspection du diff.

git rebase origin/main

cat > /tmp/claude-rebase-step.md <<'PROMPT'
Résous uniquement le conflit actuel de ce rebase.

D'abord:
- Confirme l'état rebase avec git status.
- Liste les fichiers non résolus avec git diff --name-only --diff-filter=U.
- Déduis l'intention du commit rejoué depuis le git log récent.
- Intègre cette intention avec le comportement actuel de main.

Contraintes:
- N'exécute pas git rebase --continue.
- Arrête-toi après résolution et git add.
- Ne modifie pas de fichiers sans rapport.
- Si un choix est ambigu, explique les options au lieu de deviner.
PROMPT

claude -p "$(cat /tmp/claude-rebase-step.md)"
git diff --check
npm test
git rebase --continue

On peut automatiser davantage, mais une revue à chaque étape est plus sûre. Quand un mauvais choix passe plusieurs commits, il devient difficile de retrouver le moment où le sens a changé.

Cas 3: lockfiles et code généré

package-lock.json, pnpm-lock.yaml, le code généré par OpenAPI ou Prisma et certains snapshots ne doivent pas être fusionnés ligne par ligne. Résolvez d’abord la source, puis regénérez.

cat > /tmp/claude-lockfile-policy.md <<'PROMPT'
Résous les conflits de lockfile ou de fichiers générés.

Politique:
- Résous d'abord les fichiers maintenus par des humains: package.json, schema, OpenAPI.
- Ne fusionne pas package-lock.json manuellement.
- Quand les dépendances sont décidées, regénère avec npm install.
- Pour le code généré, résous la source puis regénère.
- Explique pourquoi le diff regénéré est attendu.

Commandes autorisées:
- npm install
- npm test
- npm run lint
PROMPT

claude -p "$(cat /tmp/claude-lockfile-policy.md)"
npm install
npm test
git add package.json package-lock.json

Le piège fréquent est de garder les deux dépendances dans package.json, mais de choisir un seul côté du lockfile. Cela peut fonctionner localement et échouer en CI. Écrivez la règle: source d’abord, sortie générée ensuite.

Cas 4: comprendre pourquoi le conflit revient

La résolution est aussi un moment de rétrospective. Si les routes, les permissions, les schemas ou les dépendances entrent souvent en conflit, le problème vient souvent de la taille des PR ou d’une propriété trop partagée.

cat > /tmp/claude-conflict-retro.md <<'PROMPT'
Analyse pourquoi ce Git conflict s'est produit.

À examiner:
- Liste les fichiers avec git diff --name-only --diff-filter=U.
- Utilise git log --oneline --all -- <file> pour lire l'historique des deux branches.
- Classe la cause: propriété partagée, PR trop grande, bruit généré, règle manquante.

Sortie:
- Résumé de la cause en trois lignes.
- Règles à ajouter à CLAUDE.md.
- Dire si diviser la PR, coordonner les owners ou ajouter des tests aiderait le plus.
PROMPT

claude -p "$(cat /tmp/claude-conflict-retro.md)"

Si src/routes.ts entre en conflit chaque semaine, il faut peut-être séparer l’enregistrement des routes par fonctionnalité. Si package.json est souvent touché, des PR dédiées aux dépendances peuvent réduire le bruit.

Contrôles et règles d’équipe

Après modification, lancez au minimum:

git diff --check
git diff --name-only --diff-filter=U
npm test

Ajoutez typecheck, lint ou E2E si le conflit touche les contrats, les routes, la facturation ou l’autorisation. Pour automatiser ces contrôles, consultez le guide des hooks Claude Code.

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Bash(git merge*)|Bash(git rebase*)",
        "hooks": [
          {
            "type": "command",
            "command": "git diff --check && npm test"
          }
        ]
      }
    ]
  }
}

Documentez aussi la politique dans CLAUDE.md, la mémoire projet que Claude Code peut lire. Pour structurer ce fichier, voyez CLAUDE.md best practices et le guide de collaboration d’équipe.

## Git conflict policy
- Conserver par défaut les correctifs sécurité, autorisation et prévention de perte de données.
- Vérifier ensemble UI, API, schema et tests.
- Regénérer lockfiles et code généré au lieu de les éditer à la main.
- Pendant un rebase, une personne relit le diff avant git rebase --continue.
- Si le choix n'est pas clair, présenter les options au lieu de jeter un côté.

Pièges et résultat testé

Ne mémorisez pas ours et theirs comme des étiquettes fixes; pendant un rebase, elles surprennent facilement. Ne supposez pas non plus que “garder les deux” est toujours correct: deux validations ou deux redirections peuvent créer un comportement dupliqué. Enfin, les tests verts ne suffisent pas pour l’authentification, la facturation, les migrations ou la suppression de données.

Dans un projet TypeScript avec environ 15 fichiers en conflit, un prompt vague a corrigé la syntaxe mais oublié un test lié. Avec la politique de cet article, Claude Code a produit un diff plus petit, expliqué ses décisions et réduit le temps de revue.

Commencez par une petite branche feature: listez les fichiers non résolus, donnez une politique claire, exécutez les tests, puis relisez le diff. Quand le flux est stable, placez les règles dans hooks et CLAUDE.md pour en faire une pratique d’équipe.