Premiers commits

Ce que tu vas apprendre

• Le cycle de base : modifier, indexer, valider.
• Relire l'historique et les différences avec git log et git diff.
• Écarter les fichiers inutiles avec .gitignore et écrire des messages clairs.

Le cycle de base

Tu reprends le dépôt portfolio du chapitre précédent. Crée un fichier index.html avec un titre, puis un fichier style.css. Git ne les enregistre pas tout seul. Le travail suit toujours trois étapes :

1. Tu modifies des fichiers dans le répertoire de travail.
2. Tu choisis ce qui part dans le prochain commit avec git add : les fichiers passent dans l'index.
3. Tu valides avec git commit : l'index devient un nouveau commit dans le dépôt local.

git status : où en es-tu ?

git status est la commande que tu taperas le plus souvent. Elle ne modifie rien, elle décrit l'état du dépôt :

git status

Elle classe les fichiers en trois groupes :

• non suivis (untracked) : Git les voit mais ne les a jamais enregistrés ;
• modifiés, non indexés : ils ont changé depuis le dernier commit, mais ne sont pas dans l'index ;
• indexés : ils partiront dans le prochain commit.

Au moindre doute, tape git status. Git indique souvent la commande à utiliser ensuite.

git add : préparer le commit

git add index.html
git add style.css

Tu peux aussi tout indexer d'un coup, à partir du dossier courant :

git add .

L'index sert à choisir. Si tu as corrigé le menu et commencé une page contact, tu peux indexer seulement la correction du menu et la valider seule. Chaque commit raconte alors une seule chose.

git commit : enregistrer une version

git commit -m "Ajoute la page d'accueil"

Décortiquons cette commande :

L'option -m donne le message directement. Sans elle, Git ouvre un éditeur de texte pour que tu l'écrives.

Chaque nouveau commit pointe vers le précédent. Avance pas à pas dans le schéma pour voir l'historique se construire :

git log : relire l'historique

git log

Pour chaque commit, du plus récent au plus ancien, tu vois l'identifiant, l'auteur, la date et le message. Une version plus compacte, une ligne par commit :

git log --oneline

Appuie sur q pour quitter l'affichage si la liste est longue.

git diff : voir ce qui a changé

git diff montre les lignes modifiées qui ne sont pas encore indexées. Les lignes retirées commencent par -, les lignes ajoutées par +.

git diff

Une fois les fichiers indexés, git diff n'affiche plus rien pour eux. Pour voir ce qui partira dans le prochain commit :

git diff --staged

.gitignore : ce que Git doit ignorer

Certains fichiers n'ont rien à faire dans un dépôt : les dépendances téléchargées, les fichiers générés par le build, les secrets. Liste-les dans un fichier .gitignore à la racine du projet. Pour un projet Nuxt, par exemple :

node_modules/
.nuxt/
.output/
.env

Chaque ligne est un motif. Un nom qui finit par / désigne un dossier. Le fichier .gitignore lui-même doit être commité, pour que toute l'équipe partage les mêmes règles.

.gitignore ne concerne que les fichiers non suivis. Si un fichier est déjà enregistré, l'ajouter au .gitignore ne suffit pas : il faut aussi le retirer du suivi avec git rm --cached nom-du-fichier, qui le garde sur ton disque.

Écrire de bons messages de commit

Dans six mois, git log sera ta seule mémoire du projet. Compare :

git commit -m "modifs"
git commit -m "Corrige le menu qui se superpose au titre sur mobile"

Le second dit ce qui a changé et pourquoi. Quelques conventions répandues :

• une première ligne courte, d'une cinquantaine de caractères ;
• un verbe d'action au début : Ajoute, Corrige, Supprime, Renomme ;
• un commit pour un seul changement logique.

Si tu as besoin d'expliquer davantage, lance git commit sans -m. Dans l'éditeur, écris la ligne courte, laisse une ligne vide, puis le détail.

À retenir

• Le cycle est toujours le même : modifier, git add, git commit.
• git status décrit l'état du dépôt sans rien changer : tape-le souvent.
• git log --oneline résume l'historique, git diff et git diff --staged montrent les changements.
• Un .gitignore écarte node_modules/, les builds et surtout le .env.
• Un bon message dit ce qui change, en une ligne courte qui commence par un verbe.