Git est un système de versionnement : un outil qui sauvegarde l'état de ton projet à différents instants, t'autorise à revenir en arrière, et permet à plusieurs personnes de travailler sur la même base de code sans s'écraser mutuellement. Comparé à Google Docs ou à un Dropbox, Git fait deux choses radicalement différentes : tu décides quand sauver (et tu nommes chaque sauvegarde), et chaque sauvegarde est un état complet du projet, pas un diff incrémental.
Le modèle mental : snapshots, pas diffs
Beaucoup de gens imaginent Git comme une suite de patches successifs. Faux. Git stocke des snapshots : à chaque commit, il garde une photo complète de l'arborescence à cet instant. Les fichiers qui n'ont pas changé sont juste des références vers la version précédente (économie disque), mais conceptuellement, chaque commit est un état complet et autonome.
Conséquence pratique : tu peux te promener dans l'historique comme dans une bibliothèque de photos. Chaque commit a un identifiant unique (un hash SHA, type a3f5b6c), une date, un auteur, un message, et un parent (sauf le tout premier commit). L'ensemble forme un graphe.
Trois zones, trois rôles
Quand tu travailles, ton projet vit dans trois zones distinctes :
- Working directory : les fichiers que tu vois et que tu édites dans ton éditeur.
- Staging area (ou "index") : un sas où tu prépares ton prochain commit. Tu peux y mettre seulement certains changements et en laisser d'autres pour plus tard.
- Repository : l'historique des commits, immuable une fois posé.
Le flux normal : tu édites un fichier (working), tu fais git add fichier.txt (staging), tu fais git commit -m "..." (repository). Cette séparation est ce qui te permet de commit un sujet à la fois, même si tu as touché à dix fichiers entre-temps.
Local d'abord, distant ensuite
Git est distribué : tout l'historique de ton projet est stocké sur ta machine, dans le dossier caché .git/ à la racine du projet. Tu peux faire des commits, créer des branches, regarder l'historique, le tout sans connexion réseau.
La synchronisation avec un serveur distant (GitHub, GitLab, etc.) se fait explicitement avec git push et git pull. Tu choisis quand publier ton travail, et c'est seulement à ce moment-là que les autres peuvent le voir.
Vérifier ton install
Tu devrais voir une version (par exemple git version 2.43.0). Si la commande n'existe pas, installe Git depuis git-scm.com.
Te présenter à Git
Avant ton premier commit, Git veut savoir qui tu es. Cette config se fait une fois, globalement.
C'est cet email qui apparaîtra dans tes commits. Si tu publies sur GitHub, utilise l'email associé à ton compte GitHub pour que tes commits y soient attribués correctement.
Pour la suite
La leçon suivante te fait créer ton premier repo, ton premier commit, et te donne les commandes que tu vas utiliser tous les jours.