Maîtrisez le stage et le commit Git : vos premiers changements

Maîtriser les bases du stage et du commit Git est le premier pas concret vers une utilisation confiante de Git. Le staging vous permet de choisir exactement ce qui entre dans le prochain instantané, et le commit enregistre cet instantané avec un message que les futurs lecteurs pourront comprendre.

Si vous traitez chaque commit comme une petite unité de travail révisable, Git devient beaucoup plus facile à utiliser. Vous pouvez inspecter les modifications, diviser les modifications non liées et vous remettre des erreurs sans panique.

Comment fonctionne la zone de staging

Git ne commit pas automatiquement chaque fichier que vous modifiez. Il sépare votre travail en l'arbre de travail, la zone de staging et l'historique des commits.

L'arbre de travail est votre dossier de projet. Ce sont les fichiers que vous modifiez dans votre éditeur.

La zone de staging est la liste de contrôle de Git pour le prochain commit. Lorsque vous exécutez git add, vous n'enregistrez pas encore l'historique. Vous sélectionnez les modifications pour le prochain commit.

L'historique du dépôt est la séquence de commits déjà enregistrés.

Commencez par vérifier l'état :

git status

Git affichera les fichiers non suivis, les fichiers modifiés, les modifications stagées et votre branche actuelle. Cette commande peut être exécutée à tout moment en toute sécurité et devrait devenir une habitude.

Pour staguer un fichier nouveau ou modifié :

git add README.md

Pour staguer toutes les modifications dans le répertoire actuel :

git add .

Cette commande est pratique, mais utilisez-la avec précaution. Elle peut staguer des fichiers non liés, une configuration locale ou des fichiers générés si votre .gitignore est incomplet.

Pour une révision plus sûre, inspectez d'abord le diff :

git diff

Ensuite, ne staguer que ce qui va ensemble :

git add src/app.js
git add README.md

Après le staging, vérifiez ce qui sera commité :

git diff --staged

Cela montre l'instantané stagé exact. Si quelque chose semble incorrect, corrigez-le avant de commiter.

Faire votre premier commit

Une fois les bonnes modifications stagées, créez un commit :

git commit -m "Ajouter le README du projet"

Le message doit décrire le changement, pas l'action que vous avez effectuée. "Ajouter le README du projet" est plus utile que "modifications" ou "mettre à jour les fichiers".

Un bon commit a généralement un objectif clair. Par exemple, supposons que vous mettiez à jour un script de déploiement et que vous corrigiez également une faute de frappe dans une page de documentation. Ce sont des modifications distinctes. Staguez-les et commitez-les séparément :

git add scripts/deploy.sh
git commit -m "Ajouter la vérification de santé du déploiement"

git add docs/setup.md
git commit -m "Corriger la faute de frappe dans le guide d'installation"

Cela facilite la révision. Cela facilite également le retour en arrière si la modification du déploiement cause un problème mais que la correction de la documentation est correcte.

Si vous exécutez git commit sans -m, Git ouvre votre éditeur. Cela est utile lorsque vous avez besoin d'un message plus long :

Ajouter la vérification de santé du déploiement

Vérifier le point de terminaison du service avant de marquer le déploiement comme terminé.
Cela aide à détecter les démarrages échoués plus tôt dans le processus de publication.

La première ligne doit être courte et directe. Le corps peut expliquer pourquoi la modification était nécessaire ou mentionner des compromis.

Pour voir les commits récents :

git log --oneline -5

Cela vous donne une vue compacte de l'historique récent.

Staguer des parties d'un fichier

Parfois, un fichier contient plusieurs modifications non liées. Git peut staguer uniquement une partie d'un fichier avec le mode patch :

git add -p src/config.js

Git montre chaque bloc de modification et demande quoi faire. Les choix courants sont :

y : stager ce bloc.
n : ne pas stager ce bloc.
s : diviser le bloc en morceaux plus petits si possible.
q : quitter le mode patch.

Le staging par patch est utile lorsque vous nettoyez avant un commit. Par exemple, vous pourriez avoir un fichier où vous avez ajouté un nouveau paramètre de délai d'attente et également reformaté un commentaire. Staguez la modification du délai d'attente pour un commit, puis staguez le nettoyage du commentaire pour un autre.

Si vous avez stagé quelque chose par erreur, déstaguez-le sans perdre votre travail :

git restore --staged src/config.js

Votre fichier reste modifié dans l'arbre de travail. Il est simplement retiré de la zone de staging.

Si vous souhaitez annuler les modifications non stagées dans un fichier, soyez prudent :

git restore src/config.js

Cette commande jette les modifications locales dans ce fichier. Exécutez d'abord git diff pour savoir ce que vous perdez.

Pour plus de modèles de récupération, consultez comment annuler les erreurs Git.

Hygiène des commits pour le travail quotidien

Les commits petits et ciblés sont plus faciles à réviser, tester et annuler. Ils rendent également des outils comme git bisect plus utiles lorsque vous devez trouver où un bug a commencé.

Utilisez ces habitudes :

Exécutez git status avant le staging.
Révisez git diff avant git add.
Révisez git diff --staged avant de commiter.
Gardez les modifications non liées dans des commits séparés.
Écrivez des messages qui expliquent ce qui a changé.
Évitez de commiter des fichiers générés sauf si le projet les attend.
Ne commitez jamais de secrets, de clés privées ou de valeurs .env locales.

Un flux de travail pratique pourrait ressembler à ceci :

git status
git diff
git add src/server.js
git diff --staged
git commit -m "Gérer la réponse de vérification de santé manquante"
git status

Cette séquence n'est pas tape-à-l'œil, mais elle attrape la plupart des erreurs de débutant. Vous savez ce qui a changé, ce qui est stagé, ce qui a été commité et ce qui reste.

Si votre équipe utilise des hooks de pré-commit ou un formatage automatisé, un commit peut échouer jusqu'à ce que vous corrigiez le formatage ou les tests. Lisez le message d'erreur, exécutez la commande suggérée, staguez les modifications résultantes et commitez à nouveau.

Quand demander de l'aide

Demandez de l'aide si vous avez accidentellement stagé ou commité des secrets, si vous avez commité sur la mauvaise branche, ou si vous n'êtes pas sûr de devoir amender, annuler, réinitialiser ou faire un nouveau commit. Ces choix ont des effets différents, surtout après un push.

Vous devriez également demander avant de réécrire des commits que d'autres personnes ont pu tirer. Un simple nettoyage local peut se transformer en problème d'équipe s'il modifie l'historique partagé.

Le staging et le commit sont la boucle centrale de Git. Révisez vos modifications, staguez intentionnellement, commitez par morceaux ciblés et écrivez des messages qui auront du sens dans un mois.