Commit : Qu'est-ce qu'un commit en Git ?

Qu'est-ce qu'un commit en Git ?

Un commit est l'unité fondamentale de l'historique Git. C'est un instantané immuable de l'état complet de votre projet à un moment précis. Chaque commit est identifié par un hash SHA-1 unique de 40 caractères (souvent abrégé aux 7 premiers) et contient les modifications apportées aux fichiers, l'identité de l'auteur, un horodatage et un message descriptif.

Le commit est au coeur de la philosophie de Git. Là où un simple Ctrl+S enregistre un fichier, le commit enregistre un ensemble cohérent de modifications avec leur contexte. C'est la différence entre sauvegarder et documenter. Chaque commit raconte une partie de l'histoire du projet : pourquoi cette modification a été faite, par qui et quand.

Chez KERN-IT, nous considérons les commits comme la documentation vivante de nos projets. Un historique de commits bien écrit est aussi précieux que le code lui-même, car il permet de comprendre les décisions techniques prises au fil du temps et de retracer l'origine de chaque ligne de code.

Pourquoi les commits sont importants

Les commits sont bien plus qu'une simple sauvegarde. Ils constituent le journal de bord complet de votre projet et remplissent des fonctions critiques dans le processus de développement.

• Traçabilité complète : chaque modification est attribuée à un auteur avec une date précise. En cas de bug, git blame identifie exactement qui a modifié quelle ligne et quand.
• Réversibilité : les commits permettent de revenir à n'importe quel état antérieur du projet. Un commit problématique peut être annulé avec git revert sans perdre l'historique.
• Collaboration structurée : les commits sont l'unité de base des pull requests, des merges et des code reviews. Un bon découpage en commits facilite considérablement la revue de code.
• Bisection de bugs : git bisect utilise les commits pour identifier, par recherche dichotomique, le commit exact qui a introduit un bug. Plus les commits sont atomiques, plus cette recherche est précise.
• Documentation technique : les messages de commit constituent une documentation chronologique des décisions techniques, accessible à toute l'équipe et aux futurs développeurs du projet.

Comment ça fonctionne

Le processus de commit en Git se déroule en deux étapes. D'abord, le staging (mise en scène) : vous sélectionnez les fichiers ou les portions de fichiers que vous souhaitez inclure dans le commit avec git add. Cette étape vous permet de créer des commits précis et atomiques, même si vous avez modifié de nombreux fichiers.

Ensuite, la commande git commit -m "message" crée le commit proprement dit. Git calcule le hash SHA-1 à partir du contenu des fichiers, de l'arbre de répertoires, du commit parent et des métadonnées (auteur, date, message). Ce hash unique garantit l'intégrité de chaque commit : la moindre modification produirait un hash totalement différent.

Le staging area (aussi appelé "index") est une zone intermédiaire entre votre répertoire de travail et l'historique Git. Elle vous donne un contrôle fin sur ce qui entre dans chaque commit. La commande git add -p permet même de sélectionner des portions spécifiques (hunks) d'un fichier modifié.

L'art du message de commit

Un bon message de commit est essentiel pour la maintenabilité d'un projet. La convention la plus répandue est le format "Conventional Commits" qui structure le message selon le modèle type(scope): description. Les types courants incluent feat (nouvelle fonctionnalité), fix (correction de bug), refactor (refactoring), docs (documentation), test (ajout de tests) et chore (maintenance).

Un bon message de commit répond à la question "pourquoi" plutôt que "quoi". Le diff montre déjà ce qui a changé ; le message doit expliquer la raison du changement. Par exemple, "fix: prevent duplicate email sending on form retry" est bien plus utile que "fix email bug".

Exemple concret

Un développeur KERN-IT travaille sur un système de facturation. En une journée, il effectue plusieurs commits atomiques sur sa branche :

• feat(invoice): add automatic VAT calculation based on client country
• feat(invoice): add PDF export with company branding
• test(invoice): add unit tests for VAT calculation edge cases
• fix(invoice): handle zero-amount line items in total calculation

Chaque commit est autonome et cohérent. Si le PDF export pose problème, il peut être reverté sans affecter le calcul de TVA. Un collègue qui review la PR peut examiner chaque commit séparément, comprenant immédiatement l'intention de chaque modification grâce aux messages clairs.

Bonnes pratiques

1. Commits atomiques : chaque commit doit représenter un changement logique unique. Ne mélangez pas une correction de bug avec un ajout de fonctionnalité dans le même commit.
2. Messages clairs et descriptifs : adoptez un format de message conventionnel (Conventional Commits) et expliquez le pourquoi du changement, pas seulement le quoi.
3. Committez souvent : des commits fréquents et petits sont préférables à des commits rares et massifs. Ils facilitent la revue, le debug et la réversibilité.
4. Vérifiez avant de committer : utilisez git diff --staged pour revoir exactement ce que vous allez committer. Vérifiez qu'aucun fichier sensible ou temporaire n'est inclus.
5. Ne committez jamais de secrets : mots de passe, clés API et tokens ne doivent jamais apparaître dans un commit. Utilisez des variables d'environnement et un fichier .gitignore approprié.

Conclusion

Le commit est le pilier de Git et de toute la collaboration logicielle moderne. Bien plus qu'une simple sauvegarde, c'est un acte de documentation qui construit l'histoire de votre projet. Des commits bien découpés avec des messages clairs facilitent la revue de code, accélèrent le debugging et permettent à tout nouveau développeur de comprendre rapidement l'évolution du projet. Maîtriser l'art du commit, c'est investir dans la qualité et la pérennité de votre code.