Les commandes Git de base : init, add, commit, log

Les commandes Git de base sont celles du cycle quotidien : git init crée un dépôt, git status montre son état, git add prépare des modifications, git commit les enregistre, git log et git diff relisent l'historique. Ce chapitre les présente sur un vrai projet, en partant du modèle qui rend tout le reste logique : les trois zones de Git. Tu y apprendras aussi à écrire un message de commit qui sert à quelque chose.

Le projet fil rouge

Dans tout le cours, tu suis Lina et Hugo, deux étudiants en deuxième année de BTS SIO SLAM. Ils développent Sorbier Frais, l'application de notes de frais de Sorbier Logistique, une PME fictive : une API REST en Node.js et Express, un front en React et une base MySQL. Lina s'occupe de l'API et de la base, Hugo du front. Le projet leur sert de réalisation professionnelle pour l'E6.

Pour suivre, crée un dossier de travail et un premier fichier. Tu n'as besoin ni de Node.js ni de MySQL : les fichiers du cours sont de simples fichiers texte.

mkdir sorbier-frais
cd sorbier-frais
echo "# Sorbier Frais" > README.md

git init : créer un dépôt

git init

Initialized empty Git repository in /home/lina/sorbier-frais/.git/

Git a créé un dossier caché .git : c'est le dépôt proprement dit, avec la base de données des commits, les branches et la configuration locale. Tes fichiers, eux, restent à leur place. Affiche les fichiers cachés avec ls -a (ou Get-ChildItem -Force dans PowerShell) pour le voir.

Ne crée jamais un dépôt à l'intérieur d'un autre. Si tu ouvres un terminal dans un sous-dossier d'un dépôt, Git remonte l'arborescence jusqu'au premier .git qu'il trouve : toutes tes commandes s'appliquent au dépôt parent.

Les trois zones de Git

C'est la notion qui déroute tous les débutants, et celle qui rend tout le reste simple une fois comprise. Git ne passe pas directement de « j'ai modifié un fichier » à « c'est enregistré ». Il y a une étape intermédiaire.

1. Le répertoire de travail (working directory) : tes fichiers, tels que tu les vois et les modifies dans ton éditeur.
2. La zone de préparation (staging area, appelée aussi index) : la liste des modifications que tu as choisies pour le prochain commit. Tu y places des modifications avec git add.
3. Le dépôt local (le dossier .git) : l'historique des commits. git commit y enregistre le contenu de la zone de préparation.

Une quatrième zone s'ajoute quand tu travailles avec une forge : le dépôt distant, que git push alimente.

Pourquoi cette zone intermédiaire ? Parce qu'elle te laisse composer tes commits. Tu as corrigé un bug dans app.js et commencé une nouvelle fonction dans export.js : tu ajoutes seulement app.js, tu commites la correction, puis tu termines l'export et tu le commites à part. Chaque commit raconte une seule chose, et il pourra être annulé seul si besoin.

git status : où en suis-je ?

git status est la commande que tu tapes le plus souvent. Elle dit sur quelle branche tu es, ce qui est modifié, ce qui est préparé, et elle suggère la commande suivante.

printf 'node_modules/\n.env\n' > .gitignore
git status

On branch main

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	.gitignore
	README.md

nothing added to commit but untracked files present (use "git add" to track)

Les fichiers sont non suivis (untracked) : ils existent dans le répertoire de travail, mais Git ne les a jamais enregistrés. Un fichier passe par quatre états possibles :

git add : préparer un commit

git add README.md
git status

On branch main

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
	new file:   README.md

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	.gitignore

Le README.md est passé dans la zone de préparation ; le .gitignore attend encore. Les formes de git add que tu utiliseras :

git add -p est le meilleur ami des commits propres : il te montre chaque modification avant de la préparer, et tu repères au passage le console.log de débogage oublié.

git commit : enregistrer

git add .gitignore
git commit -m "Initialise le projet"

[main (root-commit) 24b02c7] Initialise le projet
 2 files changed, 3 insertions(+)
 create mode 100644 .gitignore
 create mode 100644 README.md

Git a enregistré le contenu de la zone de préparation. main est la branche, root-commit signale le tout premier commit, 24b02c7 est le début de son empreinte. Chez toi, l'empreinte sera différente : elle dépend de la date et de ton nom.

Si Git répond Please tell me who you are, c'est que ton nom et ton adresse ne sont pas configurés (chapitre 1). S'il répond nothing to commit, working tree clean, il n'y a rien de nouveau : soit tu n'as rien modifié, soit tu as oublié git add.

Écrire un bon message de commit

Le message est ce que toi, dans trois mois, ou la commission de l'E6, liront pour comprendre ton historique. « modif », « fix », « wip » ou « ça marche enfin » ne disent rien.

Les règles qui font consensus :

• une ligne de titre courte, autour de 50 caractères, 72 au maximum ;
• à l'impératif ou à l'infinitif, comme une consigne : « Ajoute le filtre par date », « Corriger le calcul du plafond ». Choisis l'un des deux et tiens-toi-y dans tout le projet ;
• ce que fait le commit, pas ce que tu as fait : « Corrige l'arrondi des indemnités kilométriques » plutôt que « J'ai regardé le bug » ;
• si le titre ne suffit pas, une ligne vide puis un corps qui explique pourquoi : la cause du bug, le choix fait, le numéro du ticket.

Pour un message avec un corps, lance git commit sans -m : ton éditeur s'ouvre. Ou enchaîne plusieurs -m, chacun devient un paragraphe :

git commit -m "Corrige l'arrondi des indemnités kilométriques" -m "Le calcul arrondissait chaque trajet avant la somme. On arrondit maintenant le total, comme l'exige le barème. Ticket #14."

Beaucoup d'équipes ajoutent un préfixe qui donne la nature du changement, selon la convention Conventional Commits : feat:, fix:, docs:. Le chapitre 10 la présente.

git log : relire l'historique

echo "console.log('API Sorbier Frais')" > app.js
git add app.js
git commit -m "Ajoute le point d'entrée de l'API"
git log

commit 0f0c3b3a6d2c41f1b5e7a8c9d0e1f2a3b4c5d6e7 (HEAD -> main)
Author: Lina Morel <lina.morel@example.com>
Date:   Mon Oct 12 14:03:27 2026 +0200

    Ajoute le point d'entrée de l'API

commit 24b02c7e9f8a7b6c5d4e3f2a1b0c9d8e7f6a5b4c
Author: Lina Morel <lina.morel@example.com>
Date:   Mon Oct 12 13:58:02 2026 +0200

    Initialise le projet

Les commits sont listés du plus récent au plus ancien. (HEAD -> main) signifie que tu es sur la branche main et que ce commit est son dernier. Si l'historique dépasse l'écran, Git l'affiche page par page : Espace pour avancer, q pour quitter.

Les variantes utiles :

git log --oneline

0f0c3b3 Ajoute le point d'entrée de l'API
24b02c7 Initialise le projet

Pour voir le contenu exact d'un commit, son message et ses lignes modifiées : git show 0f0c3b3. Sans argument, git show affiche le dernier commit.

git blame : qui a modifié cette ligne ?

git blame affiche, pour chaque ligne d'un fichier, le commit qui l'a écrite en dernier : empreinte courte, auteur et date.

git blame app.js
git blame -L 10,20 app.js    # seulement les lignes 10 à 20

Sur GitHub, le bouton Blame d'un fichier donne la même vue. C'est le point de départ pour comprendre pourquoi une ligne a changé : copie l'empreinte, puis git show <empreinte> affiche le commit entier et son message.

HEAD, HEAD~1 et les références

Tu désignes un commit de plusieurs façons :

Ces références servent partout : git show HEAD~1, git diff HEAD~2 HEAD, git reset --soft HEAD~1.

git diff : voir ce qui a changé

echo "// TODO : brancher la base" >> app.js
git diff

diff --git a/app.js b/app.js
index fbc902d..1fd1ef4 100644
--- a/app.js
+++ b/app.js
@@ -1 +1,2 @@
 console.log('API Sorbier Frais')
+// TODO : brancher la base

Les lignes qui commencent par + sont ajoutées, celles qui commencent par - sont supprimées, les autres servent de contexte. La ligne @@ -1 +1,2 @@ indique la zone : la ligne 1 de l'ancienne version devient les lignes 1 à 2 de la nouvelle.

Le piège : git diff sans option compare le répertoire de travail à la zone de préparation. Une fois tes fichiers préparés, il n'affiche plus rien.

Déplacer, renommer et supprimer des fichiers

Si tu supprimes ou renommes un fichier avec l'explorateur, Git le voit comme une suppression et un nouveau fichier non suivi : tu dois préparer les deux. Les commandes Git font les deux en une fois :

Git ne stocke pas les renommages : il les déduit en comparant les contenus. git log --follow fichier suit l'historique d'un fichier à travers ses renommages.

Le cycle de tous les jours

En pratique, ta journée ressemble à ceci :

git status                    # où en suis-je ?
# ... tu modifies tes fichiers ...
git diff                      # qu'est-ce que j'ai changé ?
git add -p                    # je prépare ce qui va ensemble
git diff --staged             # je relis ce qui va partir
git commit -m "Ajoute la validation du montant"
git log --oneline -5          # mon historique raconte mon travail

Commite souvent : un commit par étape qui fonctionne, pas un commit par jour. Un petit commit se relit, se comprend et s'annule facilement ; un commit de 40 fichiers « fin de journée » ne s'annule qu'en bloc. À l'E6, un historique de petits commits clairs montre ta démarche à la commission.

Exercices

On branch main
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
	modified:   src/Formulaire.jsx

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	modified:   src/App.jsx
	modified:   src/Formulaire.jsx

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	src/Export.jsx

git add app.js
git commit -m "Corrige le total des frais quand une ligne est vide"
git add routes/notes.js README.md
git commit -m "Ajoute la route GET /notes et sa documentation"