Git sans peur : comprendre commit, branche, remote, puis les commandes qui sauvent

Tu as fait une bêtise avec Git. Un commit sur le mauvais fichier, un fichier supprimé par erreur, ou le mot « CONFLICT » qui s’affiche dans le terminal sans que tu saches quoi faire. Première chose à savoir : Git n’efface presque jamais rien pour de vrai, même quand il te fait peur. Tout ce que tu as commit reste quelque part, récupérable. Cet article t’explique les trois notions de base, puis les commandes qui te sortent des situations les plus courantes, vérifiées dans la documentation officielle de Git.

Trois mots pour comprendre Git

Un commit est une photo de l’état de ton projet à un instant donné : tous tes fichiers, tels qu’ils étaient quand tu as sauvegardé. Une branche est juste un nom qui pointe vers un commit ; quand tu ajoutes un nouveau commit, ce pointeur avance tout seul. Un remote (le plus souvent nommé origin) est une copie de ton dépôt hébergée ailleurs, typiquement sur GitHub : c’est avec lui que tu synchronises ton travail via git push et git pull.

Tant que tu n’as pas fait git push, tout ce que tu fais reste local, sur ta machine. C’est important : la grande majorité des commandes de dépannage ci-dessous ne touchent que ton historique local, sans aucun risque pour le reste du monde.

Annuler ton dernier commit sans perdre ton travail

Tu viens de valider un commit trop tôt, ou avec un message bancal. La commande à connaître :

git reset HEAD~1

HEAD~1 désigne le commit juste avant celui où tu es. Par défaut, git reset fonctionne en mode --mixed : il déplace le pointeur de branche en arrière, mais laisse ton répertoire de travail intact. Concrètement, ton commit disparaît, mais le contenu que tu avais commit se retrouve avec les fichiers modifiés, prêts à être re-commit correctement.

Si tu veux vraiment jeter les changements (pas seulement le commit), il existe git reset --hard HEAD~1. Sois prudent avec --hard : il réécrit les fichiers de ton répertoire de travail pour qu’ils correspondent au commit ciblé, et les fichiers suivis qui n’existaient pas à ce commit-là sont supprimés. La documentation officielle est claire sur la limite à ne pas franchir : ne fais jamais ça si tu as déjà partagé ces commits avec quelqu’un d’autre (autrement dit, si tu les as déjà poussés sur un remote que d’autres utilisent).

Filet de sécurité local : avant chaque reset, Git enregistre automatiquement où tu te trouvais dans une référence spéciale appelée ORIG_HEAD, ce qui te permet de revenir en arrière si tu t’es trompé de commande.

Récupérer un fichier que tu as modifié ou supprimé par erreur

Pour restaurer un seul fichier à son état du dernier commit, sans toucher au reste :

git restore chemin/vers/le/fichier

Par défaut, git restore restaure le fichier depuis l’index (ce que tu as déjà ajouté avec git add), ou depuis HEAD si tu précises --staged. Tu peux aussi remonter plus loin dans l’historique avec l’option --source :

git restore --source=HEAD~2 chemin/vers/le/fichier

Cette commande ramène le fichier tel qu’il était deux commits plus tôt, sans changer quoi que ce soit d’autre dans ton projet. C’est l’outil le plus sûr quand tu veux annuler des modifications sur un fichier précis sans toucher à ton historique de commits.

Résoudre un conflit sans paniquer

Un conflit apparaît quand Git fusionne deux historiques qui ont modifié les mêmes lignes différemment (typiquement lors d’un git merge ou d’un git pull). Git ouvre le fichier concerné et y insère des marqueurs :

<<<<<<< HEAD
# Mon Projet
=======
# Mon projet génial
>>>>>>> feature-readme

Tout ce qui se trouve entre <<<<<<< HEAD et ======= correspond à ta version actuelle ; tout ce qui se trouve entre ======= et >>>>>>> feature-readme vient de l’autre branche. Il n’y a pas de mystère : tu ouvres le fichier, tu choisis ce que tu gardes (une des deux versions, les deux, ou une réécriture), puis tu supprimes complètement les trois lignes de marqueurs. Une fois le fichier propre, tu le marques comme résolu et tu termines la fusion :

git add chemin/vers/le/fichier
git commit

Si tu veux savoir, à tout moment, quels fichiers posent encore problème, git status liste les chemins encore en conflit sous « both modified ».

Ranger ton travail sans le perdre : git stash

Tu es en train de modifier des fichiers, mais tu dois changer de branche pour une urgence, sans être prêt à commit. git stash sauvegarde tes modifications locales de côté et remet ton répertoire de travail dans l’état du dernier commit. Une fois l’urgence traitée, tu peux les récupérer :

git stash list
git stash pop

git stash list affiche toutes tes mises de côté, la plus récente étant stash@{0}. git stash pop réapplique la dernière et la retire de la liste. Si tu préfères garder une copie dans la pile au cas où, utilise git stash apply à la place : il réapplique les changements sans les supprimer du stash.

Le filet de sécurité ultime : git reflog

Même après un reset --hard un peu trop rapide, tout n’est pas perdu localement. Git tient un journal de tous les déplacements de HEAD sur ta machine, qu’on appelle le reflog :

git reflog

Chaque ligne correspond à un état par lequel HEAD est passé, avec une référence du type HEAD@{2} (« où HEAD se trouvait il y a deux déplacements »). Une fois que tu as repéré la ligne juste avant ta bêtise, tu peux y revenir :

git reset --hard HEAD@{2}

Le reflog est local à ta machine et n’est pas partagé avec le remote : c’est ta roue de secours personnelle, à ne pas confondre avec l’historique visible par les autres.

Changer de branche proprement : git switch

Pour te déplacer d’une branche à l’autre, la commande moderne et sans ambiguïté est git switch :

git switch nom-de-la-branche

Pour créer une nouvelle branche et t’y positionner directement en une seule commande :

git switch -c nouvelle-branche

git switch a été introduit pour remplacer, sur ce point précis, l’ancien git checkout, qui servait à la fois à changer de branche et à restaurer des fichiers — deux usages différents mélangés dans une seule commande, source de confusion. Aujourd’hui, git switch s’occupe des branches et git restore s’occupe des fichiers, chacun avec un rôle clair.

Ce qu’il ne faut jamais faire : push –force sur une branche partagée, sans savoir

Voici la règle la plus importante de cet article. Quand tu fais git push, Git refuse normalement d’écraser l’historique distant si ton historique local n’en est pas la continuation directe. L’option --force désactive cette protection. Le risque concret, décrit noir sur blanc dans la documentation officielle : si toi et quelqu’un d’autre êtes partis du même commit, et que cette personne a déjà poussé ses propres commits, un push --force de ton côté peut faire disparaître ses commits du dépôt distant, parce que tout le monde repart désormais de ta version.

Concrètement : ne fais jamais git push --force sur une branche que d’autres personnes utilisent, sauf si tu sais exactement ce que tu fais et que tu les as prévenues. Sur une branche rien qu’à toi (par exemple ta propre branche de fonctionnalité, jamais récupérée par personne d’autre), c’est sans risque. Si tu dois quand même forcer un push sur une branche partagée après une bonne raison (un rebase concerté, par exemple), préfère --force-with-lease : cette variante vérifie que personne n’a poussé de nouveaux commits depuis ta dernière synchronisation avant d’écraser quoi que ce soit, ce qui évite d’effacer par accident le travail de quelqu’un d’autre.

À retenir

• commit = photo de ton projet ; branche = pointeur mobile ; remote = copie distante (origin).
• Annuler le dernier commit en gardant les changements : git reset HEAD~1.
• Restaurer un fichier précis : git restore chemin/du/fichier (ou --source=HEAD~2 pour remonter plus loin).
• Un conflit se résout en éditant le fichier, en supprimant les marqueurs <<<<<<< / ======= / >>>>>>>, puis git add + git commit.
• Mettre de côté sans perdre : git stash, puis git stash pop ou git stash list.
• Le filet de secours local : git reflog, puis git reset --hard HEAD@{n}.
• Changer de branche : git switch nom-branche (ou -c pour en créer une).
• Ne jamais faire git push --force sur une branche partagée sans être sûr et sans prévenir ; --force-with-lease est plus sûr.