La scène se rejoue à chaque promo de débutants. Quelqu'un veut « apprendre Git », trouve une liste de commandes sur un forum, et copie-colle. git add ., git commit -m "truc", git push. Ça marche trois fois. Puis arrive un message rouge : rejected, fetch first. Panique. Il colle une commande trouvée au hasard, un git reset --hard récupéré sur Stack Overflow, et là une journée de travail disparaît.
Git ne s'apprend pas comme ça. Ce n'est pas une liste de formules magiques à réciter, c'est un système avec un modèle interne très simple une fois qu'on l'a vu. Le débutant qui comprend ce modèle ne mémorise presque rien : il déduit les commandes. Celui qui ne fait que copier des commandes finira par tout casser, parce qu'il pilote une machine dont il ignore le fonctionnement. Voici l'ordre que je conseille, après des années à voir des gens accrocher ou décrocher sur Git.
Pourquoi apprendre les commandes par cœur échoue
Le réflexe naturel, c'est de traiter Git comme un dictionnaire : « pour annuler, je tape ça ; pour envoyer, je tape ça ». Le problème, c'est que la même intention demande des commandes différentes selon où se trouve ton fichier dans Git. « Annuler mes changements » n'a pas la même réponse si le fichier est juste modifié, déjà indexé, ou déjà commité. Sans le modèle mental, ces nuances sont incompréhensibles, et tu choisis la mauvaise commande au pire moment.
La bonne approche est inverse : tu apprends d'abord à te repérer dans le terminal sans peur, puis tu vois le modèle des trois zones de Git, et seulement après tu pratiques la boucle de base. Une fois ce schéma en tête, les commandes ne sont plus des formules à retenir, ce sont des déplacements évidents d'une zone à l'autre. Tu ne mémorises plus, tu raisonnes.
Le bon ordre d'apprentissage
Git a une progression naturelle, et le terminal en fait partie : on ne peut pas apprendre Git en fuyant la ligne de commande. Chaque étape s'appuie sur la précédente. L'étape pivot, celle qui change tout, c'est la troisième : comprendre pourquoi Git existe et ses trois zones. Tout le reste en découle.
1. Le terminal sans peur. Avant Git, il y a le terminal, et beaucoup de débutants en ont une peur irrationnelle. C'est juste une autre façon de parler à ta machine. Apprendre à se déplacer dans les dossiers, c'est le socle. Sans ça, chaque commande Git ressemble à de la magie hostile.
pwd # où suis-je ?
ls # qu'y a-t-il ici ?
cd mon-projet # j'entre dans le dossier2. Les commandes essentielles. Une poignée de commandes couvre 90 % de ton quotidien dans le terminal : créer un dossier, lire un fichier, supprimer. Pas besoin de les connaître toutes, juste celles que tu utilises vraiment. La maîtrise du terminal n'est pas un prérequis lointain, c'est la moitié du confort avec Git.
3. Pourquoi Git, et les trois zones. C'est l'étape qui débloque tout. Git n'enregistre pas tes fichiers en continu : il y a trois zones que tes fichiers traversent. Le répertoire de travail (tes fichiers actuels, ce que tu édites), la zone d'index aussi appelée staging (ce que tu as préparé pour le prochain enregistrement), et le dépôt (l'historique des enregistrements gravés). Un fichier modifié n'est pas indexé ; un fichier indexé n'est pas encore commité. Une fois ce trajet visualisé, les commandes deviennent évidentes.
4. Les premiers commits : la boucle de base. Avec le modèle en tête, tu pratiques la boucle que tu répéteras des milliers de fois. git status pour voir où en sont tes fichiers, git add pour déplacer du travail vers l'index, git commit pour graver. Cette boucle, faite jusqu'à l'automatisme, vaut mille tutos sur les branches que tu n'es pas prêt à aborder.
git status # quelles zones, quels fichiers ?
git add fichier.txt # travail -> index
git commit -m "Ajoute le fichier" # index -> dépôt5. Les branches. Seulement maintenant. Une branche, c'est une ligne de travail parallèle pour expérimenter sans casser l'existant. La notion devient simple quand les trois zones sont acquises, parce qu'une branche manipule exactement ces zones. L'aborder trop tôt, c'est garanti de s'emmêler.
6. GitHub et le dépôt distant. Jusqu'ici tout est resté sur ta machine. GitHub, c'est une copie de ton dépôt hébergée ailleurs, pour sauvegarder et collaborer. git push envoie tes commits, git pull récupère ceux des autres. Le fameux rejected du début n'a plus rien d'effrayant : c'est juste que le distant a avancé sans toi.
7. Les conflits et les bonnes pratiques. En dernier : quand deux personnes modifient la même ligne, Git ne tranche pas, il te demande de choisir. Un conflit n'est pas une erreur, c'est une question. Et autour, les habitudes qui rendent un historique lisible : commits petits et cohérents, messages clairs, .gitignore propre.
Pratiquer pour de vrai
Le frein classique avec Git, ce n'est pas la difficulté, c'est qu'on l'apprend hors sol : on lit la doc, on regarde une vidéo, et au premier vrai dépôt on a tout oublié. Git s'ancre par les mains, en tapant les commandes et en voyant les fichiers passer d'une zone à l'autre, en cassant des choses dans un bac à sable où ça ne coûte rien.
C'est exactement ce que j'ai construit dans le cours Git & terminal gratuit de ce site : chaque étape ci-dessus a sa leçon, le terminal d'abord, puis les trois zones expliquées en profondeur, puis la boucle de base avant les branches. Avec des exercices, des quiz, et le bon ordre du début à la fin. Tu tapes des commandes dès la première leçon, sans risquer ton vrai travail.
Conclusion
La meilleure façon d'apprendre Git n'est pas de collectionner des commandes : c'est de comprendre le modèle des trois zones, puis de pratiquer la boucle de base jusqu'à ce qu'elle devienne un réflexe. Les branches, GitHub, les conflits viennent après, et ils tombent naturellement parce qu'ils manipulent ce même modèle.
Le débutant qui casse tout n'est pas mauvais, il pilote à l'aveugle. Donne-lui le schéma interne d'abord, et Git cesse d'être une suite d'incantations pour devenir un outil qu'il comprend. C'est moins impressionnant qu'une liste de cinquante commandes, mais c'est la seule chose qui tient dans le temps.