Résoudre un conflit Git

Un conflit Git survient quand deux branches modifient les mêmes lignes d'un même fichier, ou quand l'une modifie un fichier que l'autre supprime : Git ne peut pas choisir à ta place, il s'arrête et te demande de trancher. Résoudre un conflit, c'est éditer les fichiers marqués, garder le bon code, retirer les marqueurs, puis git add et terminer la fusion. Ce chapitre décode les marqueurs <<<<<<<, ======= et >>>>>>>, montre la résolution dans le terminal et dans VS Code, et explique comment éviter la plupart des conflits.

Pourquoi un conflit arrive

Git fusionne tout seul la grande majorité des modifications. Si Lina modifie le haut de config.js et Hugo le bas, Git combine les deux sans rien demander. Il ne s'arrête que dans quelques cas :

Un conflit n'a rien de grave : rien n'est perdu, rien n'est cassé. Les deux versions sont sous tes yeux, et Git attend ta décision.

Le scénario

Sur main, le plafond de remboursement d'un repas est fixé à 20 € dans config.js. Lina crée feature/plafond et le passe à 25 €, comme le demande la nouvelle politique de l'entreprise. Pendant ce temps, Hugo corrige une faute sur main et, sans le savoir, change la même ligne pour mettre 22 €, un ancien chiffre trouvé dans un courriel. Lina fusionne :

git switch main
git merge feature/plafond

Auto-merging config.js
CONFLICT (content): Merge conflict in config.js
Automatic merge failed; fix conflicts and then commit the result.

Git a fusionné tout ce qu'il pouvait et s'est arrêté sur config.js. La fusion est en cours : tant qu'elle n'est pas terminée ou abandonnée, ne fais rien d'autre.

git status pendant un conflit

git status

On branch main
You have unmerged paths.
  (fix conflicts and run "git commit")
  (use "git merge --abort" to abort the merge)

Unmerged paths:
  (use "git add <file>..." to mark resolution)
	both modified:   config.js

no changes added to commit (use "git add" and/or "git commit -a")

git status liste les fichiers en conflit (both modified) et rappelle les deux issues possibles : résoudre puis commiter, ou abandonner avec git merge --abort. Les fichiers fusionnés sans problème sont déjà préparés.

Les marqueurs de conflit

Ouvre config.js :

module.exports = {
  devise: 'EUR',
<<<<<<< HEAD
  plafondRepas: 22,
=======
  plafondRepas: 25,
>>>>>>> feature/plafond
  plafondNuitee: 90,
};

Les lignes en dehors des marqueurs ont été fusionnées sans problème. Seule la zone entre <<<<<<< et >>>>>>> demande une décision.

Résoudre le conflit pas à pas

1. Comprendre les deux intentions. Pourquoi main dit 22 et la branche 25 ? Lis les messages des commits : git log --merge -p config.js affiche les commits des deux côtés qui ont touché le fichier. Si tu ne sais pas qui a raison, demande : ici, Lina vérifie la note de service, qui fixe 25 €.
2. Éditer le fichier. Garde la bonne version, ou combine les deux si les deux modifications sont utiles, et supprime les trois marqueurs :

module.exports = {
  devise: 'EUR',
  plafondRepas: 25,
  plafondNuitee: 90,
};

3. Vérifier. Cherche les marqueurs oubliés : git diff --check signale ceux qui restent. Lance l'application ou les tests : un fichier sans marqueur peut encore être faux.
4. Marquer le fichier comme résolu en le préparant :

git add config.js

5. Terminer la fusion :

git commit

Git propose le message Merge branch 'feature/plafond'. Complète-le si la décision mérite une explication : « Plafond repas à 25 € conformément à la note de service de janvier ». Tu peux aussi utiliser git merge --continue, qui fait la même chose.

Garder une version entière

Si tu sais d'avance qu'une des deux versions est la bonne pour tout un fichier, pas besoin d'éditer à la main :

git checkout --ours config.js     # garder la version de la branche courante (HEAD)
git checkout --theirs config.js   # garder la version de la branche fusionnée
git add config.js

Attention au sens : pendant un merge, ours est la branche sur laquelle tu es. Pendant un rebase, c'est l'inverse, car Git rejoue tes commits sur l'autre branche : ours désigne la branche de base, theirs tes propres commits. C'est une source d'erreur fréquente : dans le doute, ouvre le fichier.

Pour un conflit modify/delete, décide si le fichier doit exister : git add fichier pour le garder, git rm fichier pour confirmer la suppression.

Voir aussi la version d'origine

Par défaut, le conflit montre tes deux versions mais pas celle d'avant, celle de l'ancêtre commun. Or c'est souvent elle qui permet de comprendre ce que chacun a voulu faire. Active le style zdiff3 :

git config --global merge.conflictStyle zdiff3

Le conflit affiche alors une troisième section, après |||||||, avec la version de l'ancêtre commun :

<<<<<<< HEAD
  plafondRepas: 22,
||||||| 1b6c5d8
  plafondRepas: 20,
=======
  plafondRepas: 25,
>>>>>>> feature/plafond

On lit tout de suite que les deux côtés sont partis de 20 et ont chacun choisi une nouvelle valeur.

Résoudre dans VS Code

VS Code détecte les marqueurs et affiche au-dessus de chaque conflit quatre actions :

Le bouton Resolve in Merge Editor ouvre un éditeur en trois volets : les deux versions en haut, le résultat en bas. Ces boutons retirent les marqueurs pour toi, mais ils ne comprennent pas ton code : Accept Both Changes sur deux définitions de la même variable donne un fichier qui ne compile pas. Relis toujours le résultat, puis prépare le fichier et termine la fusion dans le terminal ou avec le bouton Commit de l'onglet Contrôle de code source.

Abandonner une fusion

Le conflit est plus gros que prévu, ou tu as fusionné la mauvaise branche ? Tant que tu n'as pas commité la fusion :

git merge --abort

Le dépôt revient exactement à l'état d'avant le git merge. Tu peux relancer plus tard, après en avoir parlé à ton coéquipier. Les commandes équivalentes existent pour les autres opérations qui peuvent s'arrêter sur un conflit : git rebase --abort, git cherry-pick --abort, git revert --abort.

Les conflits ailleurs qu'au merge

Le principe est toujours le même : éditer, git add, continuer. git status te rappelle à chaque fois l'opération en cours et les commandes possibles.

Moins de conflits

On n'élimine pas les conflits, mais on les rend petits et rares :

• Des branches courtes. Une branche qui vit deux jours accumule peu de différences ; une branche de trois semaines devient un cauchemar à fusionner.
• Mettre sa branche à jour souvent avec main (par git merge main ou un rebase) : tu règles les petits conflits au fil de l'eau, pas tous à la fin.
• Se répartir le travail : deux personnes qui réécrivent le même fichier le même jour vont au conflit. Les tickets et le tableau de projet servent aussi à ça.
• Des commits ciblés : reformater tout un fichier (indentation, guillemets) dans le même commit qu'une correction crée des conflits sur chaque ligne. Fais le reformatage dans un commit à part, et mets-toi d'accord sur un formateur automatique (Prettier, PHP CS Fixer) avec un fichier de configuration versionné.
• Les fins de ligne : Windows termine les lignes par CRLF, Linux et macOS par LF. Un fichier .gitattributes avec la ligne * text=auto laisse Git normaliser les fins de ligne et évite les conflits sur des fichiers « entièrement modifiés » sans raison visible.

Exercices

<<<<<<< HEAD
const MSG_REFUS = "Note refusée : justificatif manquant";
=======
const MSG_REFUS = "Note de frais refusée";
const MSG_VALIDE = "Note de frais validée";
>>>>>>> feature/libelles