Le problème que Git résout
Résumé : avant Git, développer c'était vivre avec la peur de casser son code, de perdre son travail, et d'écraser celui d'un collègue. Cette leçon décrit précisément le problème — parce qu'on ne comprend pas la solution tant qu'on n'a pas ressenti la douleur.
1. Le scénario que tout développeur a vécu
Vous travaillez sur un projet depuis deux semaines. Lundi, tout fonctionne. Mardi, vous ajoutez « juste une petite fonctionnalité ». Le soir, plus rien ne marche.
Vient alors la seule vraie question :
Comment revenir à la version qui fonctionnait lundi ?
Sans contrôle de version, la réponse est presque toujours « impossible » :
| Tentative | Résultat |
|---|---|
Ctrl+Z répété | Historique perdu depuis le redémarrage de l'éditeur |
| Copie de secours ? | Vous n'en avez pas fait |
| Mémoire | Impossible de se souvenir de chaque ligne modifiée en 8 heures |
| Corbeille système | Trop tard, elle a été vidée |
C'est la douleur numéro 1. Il y en a d'autres.
2. La méthode « dossiers datés »
Face à ce problème, la première idée d'un débutant est naturelle mais catastrophique : dupliquer manuellement le projet à chaque étape importante.
Ce que cette méthode ne permet pas :
- Savoir laquelle est la « vraie » dernière version.
- Comprendre ce qui a changé entre
v1etv2. - Savoir pourquoi un fichier a été modifié.
- Retrouver le fichier précis modifié il y a trois jours.
- Récupérer 10 Mo de disque quand le projet fait 5 Go.
Résultat : chaos, doublons, disque plein, et le doute permanent sur la version à envoyer au client.
3. Le cauchemar : collaborer à plusieurs sans versioning
Le problème devient exponentiel dès qu'une deuxième personne touche au code.
Dans ce scénario, il n'y a aucun avertissement. La personne qui a envoyé son fichier en dernier écrase le travail de l'autre. Le bug se découvre 3 semaines plus tard, en production, quand un client remonte une régression.
C'est exactement ce qui se passait en entreprise avant 2005 — l'année où Git est né.
4. Le bug en production, sans plan B
Troisième scénario, le plus stressant. Le code est en production. Un utilisateur signale un bug critique. Vous devez répondre à trois questions en moins d'une heure :
Sans historique fiable, ces trois questions n'ont aucune réponse rapide. Chaque minute perdue coûte de l'argent, des clients, de la crédibilité.
5. Ce que Git change en une phrase
Git est né précisément pour répondre à ces quatre douleurs :
| Douleur | Réponse de Git |
|---|---|
| Revenir en arrière | Retour à n'importe quelle version, en 1 commande, en < 1 seconde |
| Chaos des copies datées | Un seul dossier, un historique linéaire lisible |
| Écrasement silencieux du travail d'un collègue | Détection automatique des conflits, fusion assistée |
| Bug en production sans traçabilité | Chaque ligne du code sait qui l'a écrite, quand, et pourquoi |
En quelques années, 95 % des développeurs professionnels ont adopté Git. Pas par hasard : parce que chacun a vécu, au moins une fois, l'un des scénarios décrits ci-dessus.
Retenir en 30 secondes
- Sans contrôle de version, on perd du travail, on écrase celui des autres, et on ne peut pas revenir en arrière.
- La méthode « dossiers datés » aggrave le problème au lieu de le résoudre.
- Git est la réponse standard à ces quatre douleurs depuis 2005.
- Vous n'avez pas encore vu comment ça marche. C'est l'objet de la leçon suivante.
Suivant : Qu'est-ce que le contrôle de version ? →