Git n’a jamais eu l’intention que tu le trouves simple.

Tu penses que Git c’est juste add, commit, push ? Ca veut dire que tu as toujours joue en “mode solo”, tout au plus en cooperation sur un reseau local. Ca ne s’appelle pas utiliser Git — ca s’appelle utiliser Git comme un disque dur cloud Baidu a synchronisation manuelle.

La complexite de Git vient du probleme ultime qu’il a ete cree pour resoudre : comment faire pour qu’un groupe de programmeurs qui ne se font pas confiance, ont des horaires opposese et pourraient disparaitre a tout moment, collaborent sur le meme projet sans que tout parte en chaos ?

Vois-tu, n’importe qui peut faire clone et push. Mais des que tu commences a travailler en equipe — tu fais pull et tout n’est que conflits, l’ecran couvert de <<<<< HEAD et >>>>>> un-hash-aleatoire — c’est la que le cauchemar commence.

Je l’ai vecu moi-meme. Un nouveau developpeur backend dans notre equipe etait talentueux mais ne savait pas gerer Git. Un jour, il devait fusionner un correctif urgent, il a passe des heures sans y arriver et est venu me demander de l’aide. J’ai regarde son graphe de branches — bon sang, c’etait un enchevêtrement digne des tentacules de Cthulhu : fourches, fusions, encore des fourches, encore des fusions, entrecoupees de plusieurs commits merge branch 'master' into master insenses. Je lui ai demande ce qu’il avait fait. Il a dit : “Je n’arrivais pas a pull, alors j’ai fetch, puis rebase, rebase n’a pas marche alors j’ai merge, le merge avait encore des conflits alors j’ai reset…”

Ma tension artetielle a monte en fleche. Il traitait Git comme un puits aux souhaits — n’importe quelle commande qui sonnait bien, il la lanait en esperant que la force brute ferait un miracle. Spoiler : il n’y a pas eu de miracle, mais on a failli avoir un incident.

Et ce n’est que la partie emergmee de l’iceberg. Plus profond, on trouve les “techniques interdites” de manipulation atomique de l’historique : rebase -i, cherry-pick, filter-branch. A quoi servent-elles ? En termes simples, ce sont la “machine a remonter le temps” du monde du code — elles te permettent de retourner dans le passe et de modifier l’historique. Mais comme on le sait tous grace aux films, neuf voyageurs temporels sur dix finissent par casser l’univers. git reflog est ta pilule du regret, mais la plupart du temps tu ne sais meme pas quand tu t’es “empoisonne”.

La philosophie de conception de Git est qu’il ne fait confiance a aucune autorite centrale. Il considere l’ordinateur de chaque developpeur comme un “univers parallele” complet (repository). Chaque commit que tu fais cree un nouvel instantane historique dans cet univers. Les branches te permettent de creer d’innombrables univers paralleles a volonte. Merge et rebase sont des tentatives de reconcilier deux “lignes temporelles” differentes — pense a quel point c’est complique. Meme les physiciens n’ont pas compris tout ca !

La zone de staging existe pour que tu puisses controler avec precision ce qui est valide. Les branches isolent ton travail pour que tu n’interferes pas avec les autres. Merge gere le produit inevitable de la collaboration : la divergence. Tout cela sert un grand objectif “distribue”. Git te donne une liberte infinie — et des moyens infinis de tout faire foirer.

Alors la question est : Git est-il sans espoir ? Les gens normaux ne peuvent-ils jamais l’apprendre ?

Pas vraiment. Le probleme n’est pas Git — c’est comment on l’apprend. La plupart des tutoriels sont soit des listes de commandes style dictionnaire, soit des explications fragmentees de scenarios. La documentation officielle ressemble a un dictionnaire Xinhua de mille pages — ideal pour chercher un mot, mais on n’apprend pas a ecrire des romans avec un dictionnaire. Les guides en ligne sont eparpilles un peu partout, comme un tas de pieces Lego detachees sans notice pour te montrer comment construire le Faucon Millenium.

C’est pourquoi je recommande vivement les tutoriels qui n’essayent pas de tout couvrir mais se concentrent sur des scenarios reels a haute frequence. Je trouve que le “Guide pratique Git de zero a pro” de l’equipe de Bytedance est plutot bon.

Il t’explique la difference entre git pull et git pull --rebase et quand utiliser chacun, au lieu de te faire memoriser betement. Il te guide pas a pas a travers un cas de conflit reel, en te montrant comment le resoudre elegantment au lieu de simplement supprimer le code des autres. Il explique quand ta branche de fonctionnalite est loin derriere la branche principale, si tu dois utiliser merge ou rebase pour synchroniser, et les compromis de chaque choix.

En fin de compte, la philosophie de Git est : “Te donner une liberte infinie, et aussi te donner la corde pour te pendre.” Un bon guide t’apprend a utiliser cette corde pour tisser un filet ou escalader une falaise — pas a te faire un noeud coulant autour du cou. Notre objectif n’est pas de devenir un archeologue de Git capable de reciter toutes les commandes de memoire. C’est de devenir un artisan de Git qui navigue avec aisance en equipe, ne laisse jamais tomber ses coequipiers et peut sauver la mise quand le moment compte.