« CONFLICT : un message qui fait paniquer »
Vous fusionnez une branche, et soudain Git affiche en rouge : CONFLICT (content): Merge conflict in index.html. Le réflexe du débutant est la panique : « j'ai cassé quelque chose ». En réalité, c'est tout l'inverse. Git vous protège.
Un conflit arrive quand deux branches modifient la même ligne du même fichier de façon différente. Git ne sait pas laquelle garder, alors plutôt que de choisir au hasard et d'écraser un travail, il s'arrête et vous demande de trancher. C'est une bonne nouvelle : aucune ligne n'a été perdue.
Lire les marqueurs de conflit
Quand un conflit survient, Git insère des marqueurs dans le fichier pour montrer les deux versions :
<<<<<<< HEAD
<h1>Bienvenue sur mon site</h1>
=======
<h1>Bienvenue chez Alice</h1>
>>>>>>> nouvelle-pageLa partie entre <<<<<<< HEAD et ======= est votre version actuelle. La partie entre ======= et >>>>>>> nouvelle-page est celle de l'autre branche. Pour résoudre, vous éditez le fichier pour garder la bonne version (ou combiner les deux), puis vous supprimez les trois marqueurs. Ensuite :
# Une fois le fichier corrigé et les marqueurs retirés
$ git add index.html
$ git commit -m "Résout le conflit sur le titre de la page d'accueil"
[main b4c5d6e] Résout le conflit sur le titre de la page d'accueilC'est tout. Résoudre un conflit, c'est juste choisir le bon texte et confirmer.
.gitignore : ce qu'on ne commite jamais
Certains fichiers n'ont rien à faire dans Git : fichiers temporaires, dépendances téléchargeables, et surtout secrets. Le fichier .gitignore liste ce que Git doit ignorer :
# Dépendances (se réinstallent avec npm install)
node_modules/
# Secrets et configuration locale
.env
config.local.php
# Fichiers système et logs
.DS_Store
*.logOn ne versionne jamais node_modules/ : ce dossier pèse des centaines de Mo et se régénère tout seul. On ne versionne jamais les secrets.
Attention, danger réel : ne commitez jamais de mots de passe, clés d'API ou fichiers .env. Une fois poussé sur GitHub, un secret est considéré comme compromis pour toujours, même si vous le supprimez ensuite : il reste dans l'historique, et des robots scannent les dépôts publics en continu. Mettez ces fichiers dans .gitignore avant le premier commit.
Annuler : revert ou reset
Deux façons d'annuler un commit, très différentes :
git revert— crée un nouveau commit qui défait les changements d'un commit précédent. L'historique est préservé. C'est l'option sûre, idéale quand le commit est déjà partagé.git reset— réécrit l'historique en supprimant des commits. Puissant, mais à manier avec précaution.
# Sûr : annule un commit en en créant un nouveau qui le défait
$ git revert a1b2c3d
# Réécrit l'historique (attention)
$ git reset --soft HEAD~1 # défait le commit, garde les modifsAttention : git reset --hard supprime les commits et jette définitivement les modifications non sauvegardées. Le travail effacé est perdu, sans corbeille. Préférez git revert dès qu'un commit a été partagé, et ne lancez reset --hard qu'en sachant exactement ce que vous perdez.
"CONFLICT: a message that triggers panic"
You merge a branch, and suddenly Git shows in red: CONFLICT (content): Merge conflict in index.html. The beginner's reflex is panic: "I broke something". In reality, it is the opposite. Git is protecting you.
A conflict happens when two branches modify the same line of the same file differently. Git does not know which one to keep, so rather than choosing at random and overwriting someone's work, it stops and asks you to decide. That is good news: no line was lost.
Reading the conflict markers
When a conflict occurs, Git inserts markers into the file to show both versions:
<<<<<<< HEAD
<h1>Welcome to my site</h1>
=======
<h1>Welcome to Alice's</h1>
>>>>>>> new-pageThe part between <<<<<<< HEAD and ======= is your current version. The part between ======= and >>>>>>> new-page is the other branch's. To resolve, you edit the file to keep the right version (or combine both), then you remove the three markers. Then:
# Once the file is fixed and the markers removed
$ git add index.html
$ git commit -m "Resolve conflict on the homepage title"
[main b4c5d6e] Resolve conflict on the homepage titleThat is all. Resolving a conflict is just choosing the right text and confirming.
.gitignore: what you never commit
Some files have no business in Git: temporary files, downloadable dependencies, and above all secrets. The .gitignore file lists what Git should ignore:
# Dependencies (reinstall with npm install)
node_modules/
# Secrets and local configuration
.env
config.local.php
# System files and logs
.DS_Store
*.logYou never version node_modules/: that folder weighs hundreds of MB and regenerates on its own. You never version secrets.
Warning, real danger: never commit passwords, API keys or .env files. Once pushed to GitHub, a secret is considered compromised forever, even if you delete it afterwards: it stays in the history, and bots continuously scan public repositories. Put these files in .gitignore before the first commit.
Undoing: revert or reset
Two ways to undo a commit, very different:
git revert— creates a new commit that undoes the changes of a previous one. The history is preserved. It is the safe option, ideal when the commit is already shared.git reset— rewrites history by removing commits. Powerful, but to handle with care.
# Safe: undoes a commit by creating a new one that reverses it
$ git revert a1b2c3d
# Rewrites history (careful)
$ git reset --soft HEAD~1 # undoes the commit, keeps the changesWarning: git reset --hard removes the commits and permanently discards unsaved changes. The erased work is lost, with no trash bin. Prefer git revert as soon as a commit has been shared, and only run reset --hard knowing exactly what you are losing.
Deux usages parfaits pour l'IA : décrypter un conflit, et générer un .gitignore adapté. Copiez ce prompt :
Je vais te coller un fichier contenant un conflit de fusion Git avec ses marqueurs <<<<<<< ======= >>>>>>>. Explique-moi en français ce que représente chaque côté du conflit, ce qui les différencie, et propose-moi une version fusionnée propre sans aucun marqueur. Ensuite, génère-moi un fichier .gitignore adapté à un projet PHP avec Composer, en expliquant chaque ligne.
Sans relire la réponse de l'IA : à quoi servent les marqueurs <<<<<<< HEAD, ======= et >>>>>>>, et quelles étapes fais-tu pour résoudre le conflit ?
<<<<<<< HEAD et ======= se trouve ta version actuelle ; entre ======= et >>>>>>> celle de l'autre branche. Pour résoudre : tu édites le fichier pour garder la bonne version (ou combiner les deux), tu supprimes les trois marqueurs, puis git add le fichier et git commit. Aucune ligne n'est perdue : Git s'est juste arrêté pour que tu tranches.Écrivez un .gitignore pour un projet Node.js. Il doit au moins ignorer le dossier des dépendances (node_modules), un fichier de secrets (.env) et les fichiers de log.
Tu as un conflit de fusion en cours. L'IA te propose ces commandes pour t'en sortir. Ton rôle de relecteur : les accepter ou les rejeter, et dire pourquoi.
# « Pas le temps de lire les marqueurs, on repart propre »
$ git reset --hard HEAD
$ git clean -fdgit reset --hard HEAD jette toutes les modifications en cours, et git clean -fd supprime en plus les fichiers non suivis : tout le travail non commité de la branche fusionnée part à la corbeille, sans corbeille justement. Le conflit n'est pas un problème à fuir : on lit les marqueurs, on garde la bonne version, on supprime les trois marqueurs, puis git add et git commit. Si on veut vraiment abandonner la fusion seule, la commande sûre est git merge --abort, qui annule le merge sans détruire le reste.Sans remonter dans la leçon : dans quelle situation Git crée-t-il un conflit de fusion, et pourquoi préfère-t-on git revert à git reset --hard sur un commit déjà partagé ?
git revert sur un commit déjà partagé parce qu'il crée un nouveau commit qui défait le précédent sans réécrire l'historique. git reset --hard, lui, réécrit l'historique et jette les modifications : sur un commit que d'autres ont déjà récupéré, ça casse leur dépôt.Vous maîtrisez désormais le terminal, Git, les branches, GitHub et la résolution de conflits. Tous ces outils ne prennent vraiment sens que sur de vrais projets : place aux projets appliqués, où vous construisez quelque chose de concret du début à la fin.
Leçon 8 : Réécrire l'historique →