Git : le système de contrôle de version que Linus Torvalds a écrit en deux semaines
Ou : L’outil que tout le monde utilise, que personne ne maîtrise complètement, et que Linus Torvalds a créé parce qu’il était en colère
En 2005, Linus Torvalds — le créateur de Linux — a perdu l’accès à BitKeeper, le système de contrôle de version qu’il utilisait pour gérer le noyau Linux. Au lieu de chercher une alternative, il en a écrit une. En deux semaines. Le résultat s’appelle Git, et c’est aujourd’hui le système de contrôle de version utilisé par pratiquement tous les développeurs de la planète.
Git enregistre l’historique complet de chaque modification de chaque fichier de votre projet. Qui a changé quoi, quand, et pourquoi (si le message de commit est informatif, ce qui est un grand « si »). C’est un filet de sécurité, un outil de collaboration, et un système de voyage dans le temps — tout en un.
Commits, branches et la mécanique du code partagé
Les concepts fondamentaux
Le commit — un instantané du code à un moment donné. Chaque commit a un identifiant unique (un hash SHA), un message, un auteur, et un horodatage. C’est le « point de sauvegarde » du développeur. Vous pouvez toujours revenir à n’importe quel commit.
La branche — une ligne de développement parallèle. La branche main contient le code de production. Vous créez une branche feature/login pour développer la page de connexion. Votre travail est isolé — vous ne cassez rien pour les autres. Quand c’est prêt, vous fusionnez.
Le merge — réunir deux branches. C’est le moment de vérité : votre code et celui de vos collègues se rencontrent. Parfois ça marche. Parfois il y a des conflits — deux personnes ont modifié le même fichier au même endroit, et Git ne peut pas deviner quelle version garder. C’est à vous de trancher.
Distribué : chaque développeur a l’historique complet
La particularité de Git : c’est distribué. Chaque développeur a une copie complète du dépôt, avec tout l’historique. Pas besoin de connexion au serveur pour consulter l’historique, créer une branche, ou faire un commit. Le serveur (GitHub, GitLab, Bitbucket) n’est qu’un point de synchronisation.
Le dialogue du merge conflict
DevOps Dave : J’ai un conflit de merge. Git me montre des <<<<<<< et >>>>>>> partout.
Security Sarah : C’est Git qui te dit « je ne sais pas quelle version garder, choisis toi-même ».
DevOps Dave : Mais j’ai juste ajouté une ligne.
Security Sarah : Et ton collègue a modifié la même zone. Git ne peut pas deviner si tu veux ta version, la sienne, ou les deux. Résous le conflit, commite, et la prochaine fois, faites des branches plus courtes — moins de divergence, moins de conflits.
Tableau récapitulatif
| Concept | En une phrase |
|---|---|
| Git | Système de contrôle de version distribué — l’historique complet de votre code. |
| Commit | Instantané du code avec un message, un auteur et un hash unique. |
| Branche | Ligne de développement parallèle isolée. |
| Merge | Fusionner deux branches — parfois fluide, parfois conflictuel. |
| Pull request | Demande de review avant de fusionner une branche (GitHub/GitLab). |
Le mot de la fin
Git est un des rares outils qui est à la fois indispensable et intimidant. Les commandes de base — commit, push, pull, branch, merge — couvrent 90% des besoins. Les 10% restants — rebase, cherry-pick, bisect, reflog — sont ce qui sépare les utilisateurs de Git des personnes qui comprennent Git. Et personne ne comprend rebase du premier coup.