En bref
Versionner son code, ce n’est pas seulement sauvegarder : c’est écrire l’histoire de ton projet, et cette histoire n’a de valeur que si elle est bien racontée. L’unité de récit est le commit, et la règle qui change tout tient en un mot : atomique. Un commit égale un changement cohérent (une fonctionnalité, une correction), ni un fourre-tout de fin de journée, ni un micro-enregistrement à chaque ligne. Le message suit une grammaire simple : une première ligne courte à l’impératif qui dit ce que fait le changement (« Ajoute la validation du formulaire »), un corps optionnel qui explique pourquoi. La convention Conventional Commits (feat:, fix:, docs:…) structure le tout et se lit dans les projets sérieux du monde entier. Complète avec l’hygiène : un fichier .gitignore dès la création du projet, jamais de secrets ni de fichiers générés dans l’historique, une relecture avec git status et git diff avant chaque commit. Ton futur toi, tes coéquipiers et les recruteurs qui liront ton GitHub te remercieront.
Tu sais initialiser un dépôt, ajouter, commiter, pousser : les gestes de survie sont acquis. Reste à passer de « je sauvegarde » à « je raconte », car un historique Git peut être deux choses : une suite de « maj », « fix », « test2 » illisible, ou le journal de bord limpide d’un projet bien mené. Versionner son code proprement est une habitude qui coûte trente secondes par commit et rapporte pendant des années. Voici les règles du métier, suite directe de Git et GitHub expliqués aux débutants dans le parcours apprendre à coder.
Le commit atomique : une idée, un commit
La première question n’est pas « comment écrire le message » mais « quand commiter », et la réponse du métier tient en un adjectif : atomique. Un commit doit contenir un changement cohérent et complet, ni plus, ni moins. Une fonctionnalité qui marche. Une correction de bug. Un renommage. Les deux extrêmes à fuir se reconnaissent au premier coup d’œil dans un historique : le commit fourre-tout de fin de journée (« avancement », 47 fichiers modifiés, trois sujets mélangés), impossible à relire et surtout impossible à annuler sans tout emporter ; et la pluie de micro-commits (« test », « re-test », « ça marche », « typo ») qui noie l’information dans le bruit. Le bon rythme se trouve naturellement quand on adopte le point de vue de l’annulation : un bon commit est un changement que tu pourrais retirer d’un bloc, proprement, si tu changeais d’avis. C’est cette granularité qui rend l’historique navigable et le débogage chirurgical : retrouver QUEL changement a cassé le projet devient trivial quand chaque commit ne porte qu’une idée.
La pratique quotidienne qui rend l’atomicité possible s’appelle la zone de staging, cette étape intermédiaire entre tes fichiers modifiés et le commit, que les débutants vivent comme une complication et que les développeurs aguerris chérissent. Son intérêt : choisir précisément ce qui entre dans la photo. Tu as corrigé un bug ET amélioré un libellé dans la même séance ? Deux git add ciblés, deux commits, deux idées proprement séparées. Le geste avancé git add -p permet même de sélectionner des morceaux à l’intérieur d’un fichier. Et avant chaque commit, le rituel en deux commandes dans le terminal : git status pour voir la liste de ce qui va partir, git diff pour relire les modifications ligne par ligne. Cette relecture de trente secondes attrape une quantité étonnante d’oublis : le console.log de débogage qui traîne, le fichier de test embarqué par erreur, la modification que tu avais oubliée. Commiter sans relire, c’est publier sans se relire.
Le message : la grammaire d’un bon commit
Le message de commit a une grammaire, stabilisée par des années de pratique collective. Première ligne : courte (vise une cinquantaine de caractères), à l’impératif ou au présent, et décrivant ce que FAIT le changement : « Ajoute la validation du formulaire d’inscription », « Corrige le calcul de TVA sur les remises », « Renomme PanierClient en Panier ». Pourquoi l’impératif ? Parce que le message complète naturellement la phrase « si on applique ce commit, il va… » ; c’est la convention de Git lui-même et de l’immense majorité des projets. À bannir : les messages muets (« maj », « fix », « wip », « changements ») qui n’apprennent rien, et les romans en première ligne. Corps optionnel ensuite, séparé par une ligne vide, pour le contexte quand il compte : non pas ce que tu as changé (le diff le montre déjà) mais pourquoi : la cause du bug, la contrainte qui a dicté le choix, la piste écartée. Six mois plus tard, ce « pourquoi » vaut de l’or : le code dit toujours le quoi, seul le commit peut dire le pourquoi.
Un cran au-dessus, la convention Conventional Commits s’est imposée dans une grande partie de l’écosystème, et la connaître te rend immédiatement lisible (et fait sérieux sur un profil). Le principe : préfixer la première ligne d’un type normalisé : feat: pour une fonctionnalité, fix: pour une correction, docs:, refactor:, test:, chore: pour l’intendance. Exemple : feat: ajoute le tri des commandes par date. Le bénéfice dépasse l’esthétique : des outils lisent ces préfixes pour générer automatiquement des journaux de version, et un œil humain balaie l’historique en quelques secondes. Français ou anglais ? Même logique que pour le nommage : l’anglais est le standard des projets publics et professionnels, le français est acceptable sur un projet personnel, la cohérence est obligatoire partout. Souviens-toi enfin que ton historique est public sur GitHub : c’est l’une des premières choses qu’un recruteur regarde en parcourant ton portfolio, et une suite de messages soignés raconte un candidat rigoureux mieux qu’un CV.
L’hygiène du dépôt : ce qui n’entre jamais dans l’historique
Bien versionner, c’est aussi savoir ce qu’on NE versionne PAS, et ce point mérite d’être appris avant le premier accident. Trois familles restent à la porte. Les fichiers générés : dossiers node_modules (des dizaines de milliers de fichiers reconstructibles par npm en une commande), dossiers de build, caches. Les fichiers personnels et système : configurations locales de l’éditeur, .DS_Store et compagnie. Et surtout, les secrets : clés d’API, mots de passe, fichiers .env. Point capital : un secret commité reste dans l’historique MÊME si tu le supprimes au commit suivant, puisque Git conserve précisément toutes les versions ; des robots scannent GitHub en continu pour récolter les clés ainsi exposées. Si l’accident arrive, un seul réflexe : révoquer la clé et en générer une nouvelle. L’outil de prévention s’appelle .gitignore : un simple fichier texte à la racine listant ce que Git doit ignorer, à créer dès la naissance du projet (des modèles tout faits existent pour chaque langage sur le site gitignore.io ou dans les modèles de GitHub).
Terminons par trois gestes qui complètent la panoplie. Réparer le dernier commit : message raté ou fichier oublié, git commit --amend refait le dernier commit au lieu d’en empiler un correctif ; à réserver aux commits pas encore poussés, car il réécrit l’histoire. Les branches courtes : chaque fonctionnalité dans sa branche, fusionnée rapidement, plutôt qu’une branche fleuve de trois semaines qui divergera douloureusement ; c’est l’organisation naturelle dès qu’on déploie une version stable qu’il faut protéger. Commiter souvent, pousser régulièrement : le commit local ne protège pas ta machine, seul le push met l’historique à l’abri. Ces habitudes, prises en solo, sont exactement celles qu’exigent le travail en équipe et la contribution open source, où ton nom s’affiche à côté de chaque commit. Trente secondes de soin par commit : c’est le prix d’un historique qui te servira, au lieu d’un grenier qu’on n’ose plus ouvrir.
Questions fréquentes
À quelle fréquence faut-il commiter ?
À chaque changement cohérent et complet : une fonctionnalité, une correction, un renommage. En pratique, plusieurs fois par séance de travail. Évite les deux extrêmes : le commit fourre-tout de fin de journée qui mélange plusieurs sujets, et la pluie de micro-commits sans signification. Bon test : un commit devrait pouvoir être annulé d’un bloc, proprement.
Comment écrire un bon message de commit ?
Première ligne courte (environ 50 caractères), à l’impératif, décrivant ce que fait le changement : « Ajoute la validation du formulaire ». Si le contexte compte, ajoute après une ligne vide un corps expliquant le pourquoi. La convention Conventional Commits (feat:, fix:, docs:…) est un plus apprécié. À bannir : « maj », « fix », « wip » et autres messages muets.
Peut-on modifier un commit déjà fait ?
Oui, tant qu’il n’a pas été poussé : git commit –amend refait le dernier commit (message ou contenu). Une fois poussé sur un dépôt partagé, on évite de réécrire l’histoire : on ajoute plutôt un commit correctif. Sur un dépôt personnel que personne d’autre n’utilise, réécrire puis forcer le push reste possible, mais prends-en l’habitude avec prudence.
Que ne faut-il jamais commiter ?
Les secrets (clés d’API, mots de passe, fichiers .env) : un secret commité reste dans l’historique même supprimé ensuite, et des robots scannent GitHub pour les récolter ; en cas d’accident, révoque la clé immédiatement. Également à exclure via .gitignore : les fichiers générés (node_modules, builds, caches) et les fichiers de configuration locale.
Sources
- Pro Git, le livre officiel de référence, disponible gratuitement en français
- Conventional Commits, la spécification de la convention de messages
Cet article a une vocation informative et pédagogique. Les plateformes, outils et formations éventuellement cités le sont à titre d’exemple ; compare plusieurs options avant de t’engager ou de payer.