Pourquoi Git existe

Objectifs

À la fin de cette leçon, vous saurez :

• expliquer le problème que Git résout, avec vos mots ;
• situer working directory, zone de staging et dépôt ;
• décrire ce qu'est un commit et ce que garantit la chaîne d'historique ;
• comprendre pourquoi « distribué » change tout.

Le problème sans versioning

Sans outil dédié, tout projet qui dure finit ainsi :

projet.zip
projet-final.zip
projet-final-v2.zip
projet-final-v2-corrigé.zip
projet-final-v2-corrigé-VRAIMENT-final.zip

Trois problèmes, tous fatals à terme :

1. On ne sait plus quelle version est la bonne, ni pourquoi elle a changé — l'information vit dans votre mémoire, qui s'efface ;
2. Impossible de revenir en arrière proprement : la correction d'hier a cassé ce qui marchait, et l'ancienne version n'existe plus ;
3. Travailler à plusieurs devient un cauchemar : qui a la dernière version ? Comment fusionner deux modifications faites en parallèle ?

Git répond aux trois : il enregistre chaque état du projet avec son auteur, sa date et son message explicatif, dans une base locale appelée dépôt (repository). Revenir en arrière devient un déplacement dans l'historique ; collaborer devient une synchronisation contrôlée. C'est pour cela que Git est présent dans pratiquement chaque projet logiciel au monde — y compris celui-ci : le site Devmind que vous lisez est servi depuis un dépôt Git.

Les trois zones de travail

Le modèle mental qui explique TOUTES les commandes Git locales :

Working directory        Staging area           Dépôt (.git)
(vos fichiers)     →     (ce qui partira   →    (l'historique
                         au prochain commit)     permanent)

1. Le working directory : vos fichiers tels qu'ils sont sur le disque, en train d'être modifiés.
2. La zone de staging : la sélection exacte des modifications que vous décidez d'enregistrer au prochain commit.
3. Le dépôt (le dossier caché .git/) : la chaîne des commits déjà gravés.

Suivons le flux complet sur un exemple concret :

vous modifiez index.html        → changement visible dans le working directory
git add index.html              → le changement monte dans la staging area
git commit -m "..."             → le contenu de la staging area devient un commit
                                  dans le dépôt ; la staging se vide

Ce découpage est LA clé de Git, et sa spécificité la plus déroutante au début : on ne commite pas « son travail » globalement, on choisit précisément ce qui entre dans chaque commit. Vous avez corrigé trois choses différentes ? Trois commits distincts, chacun lisible. Cette liberté produit des historiques compréhensibles — vous le verrez au mini-défi final du chapitre.

Un commit, c'est quoi exactement

Un commit est une photo complète du projet à un instant T, accompagnée de métadonnées :

Métadonnée	Rôle
hash	identifiant unique de cette photo
parent	référence vers le commit précédent
auteur + date	qui, quand
message	POURQUOI ce changement existe

A ← B ← C ← D      (D est le dernier commit ; main pointe vers D)

Deux propriétés fondamentales découlent de cette structure chaînée :

Rien n'est jamais perdu. Chaque commit connaît son parent : revenir en arrière, c'est simplement viser un maillon antérieur de la chaîne. Vos « vieilles versions » ne sont pas des zip poussiéreux, elles sont toutes là, adressables par leur hash.

L'historique est infalsifiable. Le hash est calculé sur le contenu : arborescence complète + métadonnées + parent. Modifier un seul octet d'un ancien commit changerait son hash, donc casserait le lien de son enfant — toute altération est immédiatement visible. C'est cette propriété qui permet de faire confiance à un historique partagé entre dizaines de personnes.

Précision utile contre une idée reçue : Git ne stocke pas des diffs mais des instantanés — chaque commit référence l'état complet des fichiers (avec déduplication interne pour ce qui n'a pas changé). Conséquence pratique : consulter n'importe quelle version passée est instantané, quel que soit l'âge du commit.

Git est distribué

Votre dépôt complet — tout l'historique — vit sur votre machine. Contrairement aux anciens systèmes centralisés, vous pouvez versionner, brancher, comparer sans aucune connexion. Un remote (GitHub, GitLab) n'est qu'une copie supplémentaire de cet historique, synchronisée volontairement, dont le seul but est de partager le travail. Nous y reviendrons après avoir maîtrisé le local — car le local EST le cœur de Git.

Exercice

1. Avec vos propres mots, expliquez la différence entre working directory et zone de staging.
2. Dessinez la chaîne de commits après trois commits successifs, avec la position de main.
3. Que contient selon vous le hash d'un commit ? Pourquoi deux commits différents ne peuvent-ils pas partager le même hash ?
4. Votre collègue dit : « j'ai fait une erreur hier, je voudrais retrouver mon fichier d'avant-hier ». Qu'est-ce que Git lui répond ?

Résumé

• Sans versioning : versions empilées, retours impossibles, collaboration impossible.
• Git = historique complet, local, distribué, infalsifiable.
• Trois zones : fichiers (working directory) → sélection (staging) → historique (dépôt).
• Commit = photo complète signée, datée, chaînée à son parent.

C1 ← C2 ← C3
           ↑
          main      (et HEAD pointe main : « vous êtes ici »)