Si vous avez suivi le guide précédent jusqu'au bout, index.html et style.css sont actuellement préparés dans la staging area de mon-premier-site, et README.md attend encore d'être suivi. Il est temps de transformer cette préparation en un vrai commit.

Ce que git add ne fait pas

Une confusion fréquente consiste à croire que git add enregistre déjà quelque chose dans l'historique. Ce n'est pas le cas. La staging area est une simple sélection, qui peut encore être modifiée à volonté : vous pouvez y ajouter d'autres fichiers, en retirer, changer leur contenu et les ajouter à nouveau. Rien n'est définitif tant qu'aucun commit n'a été créé. Le commit, lui, fige un état précis dans l'historique local de votre dépôt.

Et comme vu dans le tout premier guide de ce parcours, un commit ne pousse rien sur GitHub. Il reste, pour l'instant, entièrement local à votre ordinateur.

Créer le commit

Vérifiez d'abord l'état de la staging area, par réflexe.

Deux fichiers sont prêts. Créez le commit avec l'option -m, suivie d'un message entre guillemets.

Le résultat affiché confirme plusieurs choses : le nom de la branche (main), la mention root-commit qui signale qu'il s'agit du tout premier commit du dépôt, un identifiant court propre à ce commit (ici a1b2c3d, le vôtre sera différent), votre message, et un résumé du nombre de fichiers et de lignes concernés.

Ce qui fait un bon message de commit

Un message de commit décrit le résultat obtenu, pas le geste mécanique effectué. « Ajoute la structure et le style de base » explique ce que le commit apporte au projet. Un message comme « modif » ou « update » n'aide personne, y compris vous-même dans six mois, en train de chercher où vous avez changé telle chose. Ce n'est pas une règle bureaucratique : c'est simplement pour votre propre confort futur, celui qui relira git log pour comprendre l'évolution du projet.

Vérifier que le commit existe bien

Deux vérifications suffisent. D'abord, relancez git status : il ne doit plus rien rester à committer.

Remarquez que la ligne « No commits yet » a disparu : Git sait désormais qu'un historique existe. Seul README.md reste non suivi, ce qui est normal, puisque vous ne l'avez pas encore ajouté. Ensuite, jetez un œil rapide à l'historique avec git log --oneline, une commande que vous approfondirez dans le prochain guide.

Un seul commit apparaît, avec votre message. C'est la preuve que votre travail est désormais enregistré dans l'historique local du projet.

Attention à git commit -a

Vous croiserez parfois git commit -am "message", qui prépare et commite en une seule commande les fichiers déjà suivis. Cette option ne fonctionne que sur des fichiers déjà connus de Git ; elle n'ajoute jamais un nouveau fichier non suivi comme README.md ici. Tant que vous débutez, préférez la version en deux étapes, git add puis git commit : c'est plus lent, mais nettement plus facile à contrôler.

À vous de jouer

Il reste un fichier non suivi dans votre projet : README.md. Préparez-le avec git add, puis créez un second commit avec un message qui explique ce que ce commit ajoute. Terminez par un git status pour vérifier votre résultat.

Vous ne trouvez pas la solution ? Voici la démarche attendue :

La ligne « nothing to commit, working tree clean » est celle que vous reverrez le plus souvent une fois à l'aise avec Git : elle signifie que tout ce qui a été modifié dans votre dossier a déjà été enregistré dans un commit. C'est un état parfaitement sain, souvent celui dans lequel on veut se trouver avant de commencer une nouvelle tâche.

En résumé

git add prépare des modifications pour le prochain commit, sans encore les enregistrer. git commit crée un point d'historique local à partir de ce qui est préparé. Aucune des deux commandes n'envoie quoi que ce soit sur GitHub : cette étape, le push, arrivera plus tard dans ce parcours.

Chapitre terminé