Commiter — qu'est-ce que c'est, règles de formatage et travail avec Git

Qu'est-ce qu'un commit dans Git

Un commit dans Git est un objet qui stocke l'état des fichiers du projet à un moment donné. Chaque commit contient un instantané de tous les fichiers suivis, une référence au commit parent et des métadonnées. Contrairement à d'autres systèmes de contrôle de version, Git utilise un stockage adressable par contenu — chaque objet est identifié par un hash SHA-1 de son contenu.

Lorsqu'un développeur commit des modifications, Git crée un objet commit qui stocke : un objet tree (structure de fichiers), le hash du commit parent, l'auteur, le committer, la date et le message. Cet objet est immuable — une fois créé, un commit ne peut pas être modifié sans changer son hash. Cette immuabilité garantit l'intégrité de l'historique du projet.

# Stager les modifications et commiter
git add index.html style.css
git commit -m "Fix responsive layout on mobile devices"

# Voir les détails du commit
git log --oneline -3
git show HEAD

# Stager toutes les modifications et commiter en une étape
git commit -a -m "Update dependencies to latest versions"

Les commits forment un graphe acyclique orienté (DAG), où chaque nouveau commit référence le précédent. Cela permet de naviguer dans l'historique, d'annuler des modifications et d'analyser l'évolution de la base de code. Comprendre la structure du DAG Git est la base du travail avancé avec les commits.

Comment commiter correctement les modifications

Le processus de commit dans Git comprend deux étapes : ajouter les modifications à la zone de staging (index) et créer le commit. La zone de staging permet au développeur de sélectionner les modifications spécifiques qui seront incluses dans le commit, même si de nombreux fichiers ont été modifiés dans le répertoire de travail.

La règle d'atomicité est le principe clé d'un bon commit. Chaque commit doit contenir un changement logique. Si un développeur corrige un bug et refactorise du code — ce sont deux commits différents. Les commits atomiques simplifient la revue de code, l'annulation des modifications et l'analyse de l'historique.

Avant de commiter, il vaut la peine de vérifier : s'il reste dans le code des sorties de débogage, des blocs commentés ou des modifications accidentelles. Pour cela, on utilise la commande git diff --cached, qui montre exactement ce qui sera inclus dans le commit. Une vérification supplémentaire avec git status affiche la liste des fichiers dans la zone de staging.

• Vérifiez les modifications — git diff --cached montre ce qui sera inclus dans le commit
• Vérifiez la qualité — le code doit passer le linter et les tests avant le commit
• Écrivez un message — une description claire du but de la modification
• Vérifiez les fichiers stagés — git status confirme la liste des fichiers

Règles d'écriture des messages de commit

Le message de commit est la documentation de la modification pour les futurs développeurs. Un bon message répond aux questions : qu'est-ce qui a été modifié et pourquoi. La convention Conventional Commits (équipe Angular, 2016) est devenue un standard pour de nombreux projets et définit le format : type(portée) : description.

Un bon message de commit se compose d'un en-tête (jusqu'à 50 caractères) et d'un corps (optionnel, jusqu'à 72 caractères par ligne). L'en-tête s'écrit à l'impératif : « Add » pas « Added » ni « Adds ». Capitalization et point à la fin de l'en-tête ne sont pas utilisés — c'est une convention internationale de Git.

Un mauvais message : « fix things » ou « update » — il n'apporte aucune information. Dans un mois, un développeur ne pourra pas comprendre ce qui a été exactement modifié et pourquoi. Un bon message : « fix(payment): handle timeout in stripe callback » — il devient immédiatement clair ce qui a été corrigé et où.

Erreurs fréquentes lors des commits

Les développeurs, surtout les débutants, commettent souvent des erreurs typiques lors des commits. La plus courante est un commit trop volumineux, qui mélange des dizaines de modifications. Un tel commit ne peut pas être annulé partiellement, et la revue de code devient un supplice.

La deuxième erreur la plus fréquente est un mauvais message de commit. Des messages comme « fix », « update », « changes » ou « wip » ne fournissent pas de contexte aux futurs développeurs. Dans six mois, personne ne se souviendra de ce qui a été exactement corrigé. La règle est simple : imaginez que dans un an vous regardez l'historique en essayant de trouver une modification spécifique.

La troisième erreur est de commiter du code non compilé ou non fonctionnel. Après un commit, le code doit au moins compiler. Ne pas casser la build est une exigence de base pour tout commit dans une branche partagée. Pour cela, la build et les tests sont exécutés avant le commit.

La quatrième erreur est de commiter des données confidentielles. Les clés API, mots de passe et tokens ne doivent pas se retrouver dans l'historique Git. Si un secret a déjà été commité, il ne suffit pas de le supprimer dans un nouveau commit, il faut le supprimer de tout l'historique via git filter-branch ou BFG Repo-Cleaner.

Techniques avancées de travail avec les commits

Git fournit des outils pour gérer l'historique des commits. L'un des plus utiles est git commit --amend, qui permet de compléter le dernier commit avec de nouvelles modifications ou de corriger le message. C'est pratique si le développeur a oublié d'inclure un fichier ou a fait une faute de frappe dans le message.

# Corriger le message du dernier commit
git commit --amend -m "fix(auth): correct token validation logic"

# Ajouter un fichier oublié au dernier commit
git add missed-file.txt
git commit --amend --no-edit

# Rebase interactif pour les 3 derniers commits
git rebase -i HEAD~3

Le rebase interactif est un outil puissant pour réécrire l'historique. Il permet de combiner des commits (squash), de changer des messages (reword), de réordonner (reorder) et de supprimer des commits (drop). Cependant, le rebase modifie l'historique, donc il est utilisé uniquement sur les commits locaux qui n'ont pas encore été poussés vers un dépôt distant.

Il existe deux approches pour annuler des commits. git revert crée un nouveau commit qui annule les modifications du précédent — une méthode sûre qui préserve l'historique. git reset supprime des commits de l'historique — dangereux si les commits ont déjà été poussés. Dans le développement en équipe, seul git revert est utilisé pour annuler les commits publiés.