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.
