Objectifs

À la fin de cette leçon, vous saurez :

• initialiser un dépôt avec git init ;
• observer l'état du projet avec status avant chaque action ;
• sélectionner et enregistrer des modifications (add, commit) ;
• lire l'historique (log) et les différences (diff).

🔗 Pour vous rafraîchir la mémoire : pourquoi Git existe

Initialiser le dépôt

mkdir mon-projet && cd mon-projet
git init

Sortie :

Initialized empty Git repository in /home/cours/mon-projet/.git/

git init crée un dossier caché .git/ : c'est là que vivent l'historique et toute la configuration. Votre dossier devient un dépôt Git — et rien d'autre ne change : vos fichiers restent à leur place, intacts. Supprimer .git/ effacerait tout l'historique sans toucher aux fichiers actuels ; c'est dire combien « le dépôt » et « les fichiers » sont deux choses distinctes.

Observer avant d'agir : git status

Créons un fichier puis interrogeons Git :

echo "# Mon projet" > README.md
git status

Sortie commentée :

On branch master          ← vous êtes sur la branche par défaut

No commits yet            ← l'historique est vide pour l'instant

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        README.md         ← Git VOIT le fichier mais ne le SUIT pas encore

nothing added to commit but untracked files present

Le mot-clé est untracked : Git voit ce fichier sur le disque, mais il n'apparaît dans aucun commit — si vous le supprimiez maintenant, aucun regret possible. Les trois états possibles d'un fichier :

État	Signification	Vu dans
untracked	jamais enregistré dans Git	rouge
modified	suivi, mais changé depuis le dernier commit	rouge
staged	sélectionné pour le prochain commit	vert

Habitude professionnelle absolue : git status avant chaque action. C'est gratuit, instantané, sans aucun risque — et ça élimine 90 % des surprises (« pourquoi mon commit est vide ? », « où est passé mon fichier ? »).

Enregistrer une photo : add puis commit

git add README.md          # monte le fichier dans la zone de staging
git status                 # README.md est passé en vert (staged)

Puis :

git commit -m "Premier commit : README"

Sortie :

[master (root-commit) a1b2c3d] Premier commit : README
 1 file changed, 1 insertion(+)
 create mode 100644 README.md

Lecture : premier commit de la chaîne (root-commit), hash abrégé a1b2c3d, un fichier ajouté. L'instantané complet du projet vient d'être gravé dans .git/.

Le message entre guillemets décrit le pourquoi du changement. Convention utile : première ligne courte au présent de l'impératif (« Ajoute X », « Corrige Y »), détails ensuite si besoin. Comparez :

"modifs"                        ← inutilisable dans six mois
"Ajoute la structure de dossiers du cursus"   ← compréhensible pour toujours

⚠️ Piège classique : commiter sans avoir rien stagé. Git répond alors poliment :

nothing to commit, working tree clean

— ce qui signifie précisément : « tes fichiers sont identiques au dernier commit ». Relisez git status : c'était écrit.

Le cycle complet, avec vérification à chaque étape

Ajoutons une modification pour voir diff entrer en scène :

echo "Un cursus pour apprendre." >> README.md
git diff

diff --git a/README.md b/README.md
index e69de29..3b18e51 100644
--- a/README.md      ← version AVANT (le dernier commit)
+++ b/README.md      ← version APRÈS (votre disque)
@@ -1 +1,2 @@
 # Mon projet
+Un cursus pour apprendre.    ← ligne AJOUTÉE (préfixe +)

git diff compare working directory ↔ dernier commit : exactement ce qui changerait si on commitait maintenant. Les lignes - ont disparu, les lignes + sont apparues. Ensuite :

git add README.md
git diff                   # ...n'affiche plus RIEN !
git diff --staged          # voilà le changement : il est désormais STAGÉ
git commit -m "Complète la description du projet"

Subtilité capitale démontrée ici : après add, le changement vit dans la staging area — git diff (qui compare au working directory) ne le voit plus ; git diff --staged (staging ↔ dernier commit) le montre. Si votre diff semble vide juste avant un commit attendu, c'est presque toujours cela.

Lire l'historique

git log --oneline

f4e5d6c Complète la description du projet
a1b2c3d Premier commit : README

Chaque ligne : hash abrégé + message, du plus récent au plus ancien. git log complet ajoute auteur, date et hash intégral — quittez avec q. Le hash sert d'adresse : git show a1b2c3d affiche ce commit précis (message + diff).

Le réflexe professionnel résumé

git status           # avant chaque action (gratuit, sans risque)
git diff             # que vais-je enregistrer ?
git add <fichiers>   # je choisis précisément
git commit -m "..."  # je grave avec une intention nommée
git log --oneline    # je relis l'histoire produite

Ces six commandes suffisent pour 90 % du travail quotidien solo. Elles deviennent des réflexes musculaires dès cette semaine.

Exercice

1. Initialisez un dépôt carnet-de-bord contenant un fichier jour-01.md (trois lignes quelconques), commit initial.
2. Modifiez le fichier, observez git status ET git diff, puis faites un second commit.
3. Affichez l'historique compact et retrouvez le hash du premier commit.
4. Modifiez encore, exécutez git add, puis git diff et git diff --staged : décrivez la différence entre les deux sorties.
5. Question piège : que fait git add ? Beaucoup répondent « il enregistre ». Quelle est la vraie réponse ?

Résumé

• git init transforme un dossier en dépôt (tout vit dans .git/).
• Cycle de base : modifier → observer (status, diff) → add → commit.
• Après add, le changement passe de diff à diff --staged.
• Un bon message dit le pourquoi ; le diff dit déjà le quoi.
• status avant, log --oneline après : les deux garde-fous gratuits.

f4e5d6c Ajoute le bilan du jour un

a1b2c3d Démarre le carnet de bord ← le premier commit, en bas

L'historique se lit du plus récent (haut) au plus ancien (bas) : le premier commit est donc la dernière ligne.

**Exercice 4.** Après le `add` :
- `git diff` n'affiche **rien** : il compare working directory ↔ dernier commit, et le changement est monté en staging ;
- `git diff --staged` affiche la modification (lignes `+`), car lui compare staging ↔ dernier commit.
La modification existe toujours ! Elle a simplement changé de zone — leçon directe des trois zones de la leçon précédente.

**Question 5.** `git add` n'enregistre **rien définitivement** — il met en scène le prochain commit (il copie l'état actuel du fichier dans la staging area). On peut `add` puis modifier encore puis re-`add` : seul le dernier état stagé sera pris. Seul `git commit` écrit dans l'historique. Cette confusion est LA faute de frappe conceptuelle du débutant : « j'ai fait add, où est mon commit ? » — nulle part, tant que `commit` n'a pas été tapé.

mkdir carnet-de-bord && cd carnet-de-bord
git init
printf "Jour un.\nPremières notes.\nObjectifs.\n" > jour-01.md
git status                  # untracked
git add jour-01.md
git commit -m "Démarre le carnet de bord"

echo "Bilan : bonne journée." >> jour-01.md
git status                  # modified
git diff                    # + Bilan : bonne journée.
git add jour-01.md
git commit -m "Ajoute le bilan du jour un"

git log --oneline