Les trois zones et ton premier commit
L'idée la plus importante de Git
Quand tu travailles avec Git, chaque modification passe par trois zones.
Zone 1 : le dossier de travail. Ce sont tes fichiers, tels que tu les vois et les modifies. Quand tu modifies un fichier, la modification est ici, et seulement ici. Git l'a remarquée, mais ne l'a pas enregistrée.
Zone 2 : la zone de préparation (en anglais staging area, ou index). C'est la liste de ce qui ira dans la prochaine photo. Tu y mets des fichiers avec la commande git add.
Zone 3 : l'historique. Ce sont les photos déjà prises. La commande git commit prend tout ce qui est dans la zone de préparation et en fait une photo définitive.
ZONE 1 ZONE 2 ZONE 3
Dossier de travail Zone de préparation Historique
(tes fichiers) (prochaine photo) (photos prises)
---- git add fichier ----> ---- git commit ---->
Une photo de classe
Imagine que tu organises une photo de classe.
- Le dossier de travail, c'est la cour de récréation, avec tous les élèves.
- La zone de préparation, c'est l'estrade devant l'appareil. Avec
git add, tu fais monter un élève sur l'estrade. git commit, c'est appuyer sur le bouton : la photo contient seulement les élèves sur l'estrade. Ceux restés dans la cour n'y sont pas.
Pourquoi une zone au milieu ?
Pour choisir ce qui va dans chaque photo. Exemple : tu as corrigé une erreur de calcul dans calcul.py et, en même temps, ajouté une leçon dans lecon.md. Ce sont deux choses sans rapport. Tu fais deux photos :
git add calcul.py
git commit -m "Corrige le calcul de la moyenne"
git add lecon.md
git commit -m "Ajoute la leçon sur les listes"
Dans trois mois, si la moyenne pose encore problème, tu retrouves tout de suite le bon commit, sans qu'il soit mélangé avec autre chose.
Les commandes de ton premier commit
| Commande | Ce qu'elle fait |
|---|---|
git init |
transforme le dossier courant en dépôt (crée le dossier caché .git). Une seule fois par projet. |
git status |
dit dans quelle zone se trouve chaque fichier. À taper tout le temps. |
git add README.md |
met README.md dans la zone de préparation |
git add . |
met tout le dossier courant dans la zone de préparation (le . veut dire « ici », tu te souviens ?) |
git commit -m "message" |
prend la photo. -m est une option qui veut dire message. |
git log --oneline |
affiche l'historique, un commit par ligne |
Toutes les commandes Git suivent le même modèle que le terminal : git, puis une sous-commande (status, add, commit), puis options et arguments.
Ce que tu verras après un commit
[main (root-commit) 4f2a9c1] Ajoute le README
1 file changed, 3 insertions(+)
main: le nom de la ligne d'historique principale (on dit la branche, leçon 6) ;root-commit: c'est le tout premier commit, la « racine » de l'historique ;4f2a9c1: l'identifiant du commit ;1 file changed, 3 insertions(+): un fichier modifié, 3 lignes ajoutées.
Le piège du message oublié
Si tu tapes git commit sans -m "...", un vrai terminal ouvre un éditeur de texte pour te demander le message, et on ne sait souvent pas comment en sortir :
- si tu vois
GNU nanoen haut : écris ton message, puisCtrl + O, Entrée,Ctrl + X; - si tu vois des
~partout à gauche (c'est l'éditeur vim) : appuie surÉchap, tape:q!puis Entrée, et recommence avec-m.
Pratique : Ton premier commit
Suis les objectifs dans l'ordre. Après chaque commande Git, tape git status et observe ce qui a changé : c'est comme ça qu'on comprend les zones.
Un terminal simulé t'attend dans l'appli, sans rien installer. Pratiquer
Teste-toi
Tu as modifié a.py et b.py, puis tapé git add a.py et git commit -m "...". Qu'y a-t-il dans la photo ?
- Les deux fichiers modifiés
- Seulement
a.pymodifié ; la modification deb.pyreste dans le dossier de travail (bonne réponse) - Rien, il fallait d'abord pousser sur GitHub
- Seulement
b.py
b.py est toujours modifié dans le dossier de travail. Il pourra aller dans un prochain commit.