Comprendre le modèle Git

Git peut faire peur au début : des commandes bizarres, du vocabulaire anglais, des schémas qui ressemblent à des plans de métro. Mais derrière tout ça se cache une idée très simple. Pour la comprendre, on va utiliser une image qui va nous accompagner pendant tout le chapitre : un photographe et son cahier.

Imagine un photographe qui documente un projet. Il prend des photos sur son appareil, il en sélectionne quelques-unes qu'il juge importantes, puis il les colle sur une page de son cahier pour garder une trace datée de son travail. Le lendemain, il recommence : nouvelle page, nouvelles photos. Au fil du temps, son cahier devient l'histoire complète du projet, page après page.

Git fonctionne exactement comme ça — sauf qu'à la place des photos, ce sont tes fichiers de code, et qu'à la place du cahier, c'est ton ordinateur. Chaque geste du photographe a son équivalent dans Git. Voici les correspondances à retenir :

Maintenant, à toi de jouer — relie chaque élément à son équivalent Git :

Avant de plonger dans les commandes, posons-nous la vraie question : pourquoi a-t-on inventé un outil comme Git ?

Quand tu travailles sur un projet, tu modifies des fichiers en permanence. Sans outil adapté, tu finis vite avec des dossiers du genre projet_final, projet_final_v2, projet_VRAIMENT_final. Impossible de savoir qui a changé quoi, ni de revenir proprement à une version qui marchait il y a trois jours.

Git a été créé en 2005 par Linus Torvalds — le créateur de Linux. Il avait besoin d'un outil capable de gérer un énorme projet de code, sur lequel des milliers de personnes contribuent en même temps, partout dans le monde, et sans dépendre d'un serveur central.

Avant Git, les développeurs utilisaient des outils comme SVN ou CVS. Ces outils avaient un défaut majeur : ils avaient besoin d'un serveur central. Si ce serveur tombait en panne — ou si tu n'avais pas internet — plus personne ne pouvait enregistrer son travail.

C'est la idée la plus importante du chapitre, alors prenons le temps. La plupart des anciens systèmes (comme SVN) enregistrent les différences : « à la ligne 3, remplace Hello par Bonjour ». Pour reconstruire la version d'aujourd'hui, ils doivent rejouer toutes les modifications depuis le tout début — c'est lent, et fragile si une seule différence est corrompue.

Git fait l'inverse. À chaque commit, il prend une photo complète de tous tes fichiers, comme une page de cahier qui montre l'intégralité du projet à cet instant. Pour retrouver une version, il n'a rien à recalculer : il ouvre directement la bonne page. Regarde la différence :

Tu te demandes peut-être : « une photo complète à chaque fois, ça ne prend pas une place énorme ? » Bonne question — et non. Si un fichier n'a pas changé, Git ne le recopie pas : il garde juste un lien vers la version précédente. Tu obtiens donc le confort de la photo complète, sans gaspiller d'espace.

Voici sans doute le concept le plus utile de tout le chapitre au quotidien. Git ne sauvegarde pas tes fichiers d'un coup : il les fait passer par 3 zones, l'une après l'autre. Une fois que tu as ces 3 zones en tête, 90 % des commandes Git deviennent logiques.

Reprenons le photographe. Il prend des photos sur son appareil (le Working Directory), il en pose quelques-unes sur un plateau pour choisir lesquelles garder (la Staging Area), puis il colle la sélection sur une page de son cahier (le Repository). Chaque zone a un rôle précis :

Tu pratiqueras ces commandes en détail au chapitre 2.

Git stocke les données sous forme de 4 types d'objets. Voici comment ils s'organisent :

À toi de jouer — relie chaque objet à son rôle :

Comment Git stocke concrètement les données

Voici ce qui se passe réellement quand tu crées un fichier et tu le commites :

Tu n'as pas besoin de retenir ces commandes. L'important est de comprendre que Git stocke des objets reliés entre eux : le commit pointe vers un tree, le tree pointe vers des blobs.

On vient de voir que Git stocke des objets (blob, tree, commit). Mais comment les retrouve-t-il, sans jamais se tromper, parmi des milliers d'objets ? Grâce au hash.

Un hash, c'est une empreinte digitale calculée à partir du contenu. Git passe le contenu de l'objet dans une fonction mathématique (SHA) qui produit un code de 40 caractères. Ce code a deux propriétés magiques : le même contenu donne toujours le même hash, et le moindre changement (une virgule, un espace) donne un hash complètement différent.

C'est ce qui garantit l'intégrité de ton historique : si une donnée est modifiée, ne serait-ce que d'un caractère, son hash ne correspond plus et Git le détecte immédiatement. En pratique, on utilise souvent juste les 7 premiers caractères. Essaie par toi-même — tape un texte, puis change une seule lettre :

Le hash garantit que les données sont intactes. Si un seul caractère change dans un fichier, le hash sera complètement différent. Impossible de modifier l'historique sans que Git le détecte.

Les branches sont ce qui rend Git si puissant pour travailler à plusieurs — ou pour tester une idée sans casser ce qui marche. Mais attention au piège classique : beaucoup de débutants imaginent qu'une branche est une copie de tout le projet. C'est faux, et comprendre pourquoi change tout.

Une branche, c'est juste un petit fichier qui contient le hash d'un commit — littéralement un marque-page qui dit « la dernière page de cette ligne de travail, c'est celle-là ». La créer ne copie rien et est donc instantané, même sur un projet de plusieurs gigaoctets.

Conséquence concrète : tu peux créer une branche pour chaque fonctionnalité, chaque correction de bug, chaque expérience — sans hésiter, sans rien dupliquer. Quand tu ajoutes un commit, le marque-page de ta branche avance tout seul vers la nouvelle page. Et main n'a rien de spécial : c'est une branche comme les autres, juste celle créée par défaut.

Concrètement, Git stocke chaque branche comme un fichier dans le dossier .git/refs/heads/ :

Tu créeras et fusionneras des branches au chapitre 3.

Si une branche est un marque-page, HEAD est ton doigt posé sur le marque-page que tu lis en ce moment. Comme tu peux avoir plusieurs marque-pages (plusieurs branches) dans le cahier, Git a besoin de savoir lequel est « actif » : c'est exactement le rôle de HEAD.

La plupart du temps, HEAD pointe vers une branche, et cette branche pointe vers un commit. Quand tu fais un nouveau commit, la branche avance d'une page… et HEAD la suit automatiquement. Tu restes toujours « à la dernière page » de ta branche :

Il existe un cas particulier que tu croiseras tôt ou tard : le detached HEAD(« HEAD détaché »). Cela arrive quand HEAD pointe directement sur un commit, sans passer par une branche — par exemple quand tu fais git checkout sur un vieux commit pour regarder ce qu'il contenait.

On a vu les commits, les branches et HEAD. Si on prend du recul, tous ces objets s'assemblent en une seule grande structure : l'historique de ton projet. Et cet historique n'est pas une simple liste — c'est un graphe.

Chaque commit garde un lien vers son parent : le commit qui le précède. C'est comme un arbre généalogique où chaque enfant connaît ses parents. Ce détail est ce qui permet à Git de toujours pouvoir remonter le temps : depuis n'importe quel commit, il peut reconstituer toute la lignée jusqu'au tout premier.

Quand deux branches se rejoignent (une fusion), le commit de fusion a même deux parents — c'est ce qui crée les « fourches » que tu vois dans le graphe. On appelle ça un DAG (graphe orienté sans cycle) : on avance toujours du passé vers le présent, jamais en boucle.

Tu peux visualiser ce graphe à tout moment avec cette commande :

Jusqu'ici, tout se passait sur ta machine. Et c'est une force de Git : ton dépôt, avec tout son historique, vit en entier sur ton ordinateur. C'est ton dépôt local. Tu peux commiter, créer des branches, consulter l'historique… même dans un avion, sans aucune connexion.

Mais pour travailler en équipe (ou simplement sauvegarder ailleurs que sur ton disque dur), il te faut un point de rendez-vous commun : un dépôt distant(en anglais : remote). C'est une copie du projet hébergée sur un serveur, par exemple sur GitHub, GitLab ou Bitbucket.

Dans notre analogie, c'est comme si chacun avait son propre cahier de photographe, et qu'il existait en plus un grand cahier partagé au milieu du bureau. Deux commandes servent à synchroniser ton cahier avec le cahier partagé :

git push : envoyer tes commits

Quand tu as fait un ou plusieurs commits en local, tu peux les envoyer vers le dépôt distant avec git push.

git pull : récupérer les nouveautés

Quand d'autres personnes ont poussé des commits sur le dépôt distant, tu peux les récupérer avec git pull. Cette commande fait deux choses : elle télécharge les nouveaux commits (fetch) puis les intègre dans ta branche (merge).

L'important à retenir : tu peux travailler sans connexion internet. Tu synchronises quand tu veux avec push et pull.

Voici comment tous les concepts de ce chapitre s'emboîtent :

Avant de passer aux exercices, vérifie que tu as compris les concepts. Clique sur la réponse qui te semble correcte.