Lire l’état du dépôt

Après votre premier commit, vous avez besoin de savoir ce qui a changé avant d’enregistrer une nouvelle version. Sans cette vérification, vous pourriez oublier un fichier ou préparer un changement que vous ne souhaitiez pas inclure. La commande git status vous donne une vue synthétique de l’état du dépôt.

Vous travaillez dans le dossier suivi-site, qui contient déjà index.html, style.css et README.md. La zone de préparation et le premier commit ont été présentés dans la leçon précédente ; ici, vous apprenez à lire les indications que Git fournit sur ces fichiers.

Vérifier un dépôt après le premier commit

Ouvrez un terminal dans le dossier du projet, puis lancez la commande. Si aucun fichier n’a été modifié depuis le commit, Git indique que la branche est à jour et que l’arbre de travail est propre. Le nom de branche peut varier selon votre installation ; le point important est l’absence de changements à enregistrer.

cd suivi-site
git status

Sur la branche main
rien à valider, la copie de travail est propre

Git compare les fichiers présents dans le répertoire de travail avec les versions qu’il connaît. Pour voir un changement concret, ajoutez une ligne de suivi dans le fichier README, puis relancez git status. Cette commande ne modifie pas le projet : elle affiche uniquement les informations nécessaires pour décider de la suite.

printf '\nContrôler l’état du dépôt avec git status.\n' >> README.md
git status

Sur la branche main
Modifications qui ne seront pas validées :
  modifié : README.md

Lire les catégories de fichiers

Dans ce résultat, README.md est un fichier modifié : Git le suit déjà, mais son contenu a changé depuis la version enregistrée. La mention « ne seront pas validées » signifie que le changement n’est pas encore dans la zone de préparation. Vous pouvez donc repérer séparément les modifications faites dans le projet et celles qui sont prêtes à être incluses dans un prochain commit.

Un fichier créé dans le dossier du projet, mais encore inconnu de Git, apparaît comme non suivi. Par exemple, si vous créez un nouveau fichier dans le projet, git status l’indique dans la section des fichiers non suivis. Le contrat de ce site limite les fichiers du projet à index.html, style.css et README.md : ne créez donc pas de fichier supplémentaire pour cet exemple.

Un fichier déjà placé dans la zone de préparation apparaît dans une section distincte, généralement sous une formulation équivalente à « changements à valider ». Cette indication vous permet de contrôler ce qui serait inclus dans le prochain commit, sans confondre ces fichiers avec les changements encore non préparés. Si un fichier apparaît dans les deux catégories, il peut avoir été modifié de nouveau après sa préparation.

Contrôler l’état après une action

Prenez l’habitude d’exécuter git status après avoir modifié des fichiers et avant de préparer un commit. Vous pouvez également le relancer après une action pour vérifier que Git affiche bien l’état attendu. Dans cette leçon, la ligne ajoutée à README.md reste modifiée et non préparée ; vous pouvez la conserver pour poursuivre le travail dans la leçon suivante.

À retenir

• Lancez `git status` depuis le dossier du projet pour obtenir une vue de son état.
• Un fichier modifié est déjà suivi par Git, mais son contenu diffère de la version enregistrée.
• Un fichier non suivi est présent dans le projet, mais Git ne le suit pas encore.
• Les changements préparés et non préparés apparaissent dans des sections distinctes.
• La ligne ajoutée à `README.md` reste modifiée et non préparée après cette leçon.

Dans la leçon suivante, vous examinerez précisément le contenu des changements non préparés avec git diff.