Avant de taper la moindre commande, il faut comprendre comment Git pense. Git ne stocke pas des différences entre fichiers : il prend des snapshots (instantanés) complets de votre projet à chaque commit. Ce module pose ce socle en six leçons : pourquoi versionner, l'histoire du contrôle de version, le modèle par snapshots, l'installation de Git, l'aide intégrée et le vocabulaire que toute la formation emploie ensuite.
Ce que vous allez apprendre : le fil du module
Section intitulée « Ce que vous allez apprendre : le fil du module »Le module avance du pourquoi au comment, puis aux outils de travail. La première leçon, Pourquoi versionner, ne parle pas encore de Git : elle explique ce qu'un outil de gestion de version garantit à une équipe, développeurs comme administrateurs : traçabilité, retour arrière, travail à plusieurs et intégrité de l'historique. Ces garanties sont la grille avec laquelle vous jugerez tout le reste.
La leçon Historique du contrôle de version montre ensuite comment ces garanties ont été conquises, des outils locaux comme RCS aux serveurs centralisés, puis aux systèmes distribués dont Git fait partie. Comprendre d'où vient Git explique pourquoi il fonctionne comme il fonctionne.
Le modèle par snapshots entre alors dans la mécanique : les trois états d'un fichier (working directory, staging area, repository), l'intégrité par SHA et la différence avec les systèmes à deltas. C'est le cœur conceptuel du module.
Les trois dernières leçons équipent votre poste et votre mémoire.
Installer et configurer
prépare Git avec les bons réglages dès le départ (identité, éditeur,
alias). Obtenir de l'aide
vous apprend à chercher la réponse dans le terminal avec git help et les
pages de manuel. Enfin, le
Vocabulaire Git définit une
quarantaine de termes, de HEAD au reflog : il sert de dictionnaire de
référence pour toute la formation, à consulter autant qu'à lire.
Pourquoi commencer par la théorie ?
Section intitulée « Pourquoi commencer par la théorie ? »La plupart des erreurs Git viennent d'une mauvaise compréhension du modèle. Quand vous savez que Git travaille avec trois zones (working directory, staging, repository) et que chaque commit est un snapshot complet, les commandes deviennent logiques. Le tableau met en regard trois questions de débutant et la réponse qu'apporte le modèle :
| Sans comprendre le modèle | Avec le modèle en tête |
|---|---|
« Pourquoi git add avant commit ? » | Le staging permet de choisir précisément ce qui entre dans le commit |
| « C'est quoi HEAD ? » | HEAD désigne la branche active, qui pointe elle-même vers son dernier commit ; en HEAD détaché (un ancien commit consulté hors de toute branche), il désigne directement ce commit |
| « Pourquoi mes fichiers ne sont pas dans le commit ? » | Ils n'ont pas été ajoutés à la staging area |
Ce module ne vous fait presque rien taper, et c'est voulu. Le module
Le cycle de travail quotidien met ces notions en pratique dès le
premier git init : vous y retrouverez les trois états,
cette fois commande par commande, avec la sortie attendue à chaque
étape.
À retenir
Section intitulée « À retenir »- Versionner apporte quatre garanties : traçabilité, retour arrière, travail à plusieurs et intégrité de l'historique
- Git est un système distribué : chaque développeur a une copie complète de l'historique
- Git pense en snapshots, pas en différences entre fichiers
- Vos fichiers passent par 3 états : working directory, staging area, repository
- Une bonne configuration initiale évite des problèmes récurrents
- L'aide intégrée (
git help) est votre premier réflexe avant de chercher sur le web