# Git : le système de contrôle de version que Linus Torvalds a écrit en deux semaines

> Git enregistre chaque modification de votre code. Chaque commit est un point de sauvegarde. Chaque branche est un univers parallèle. Et merge est le moment où ces univers se rencontrent.


*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é

{.subtitle}

### 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.