Il y a plein de façon d'organiser ses commits. L'une des méthodologies est appelée "le commit atomique", vous trouverez pas mal d'autres articles sur le sujet.
Quand je parle de commit atomique à d'autres développeurs, il y a souvent une confusion sur sa taille, qui logiquement devrait être "aussi petit que possible, comme un atome", or pour moi ce n'est pas le plus important, et ça peut même être trompeur.
Je n'ai pas trouvé de mot pour remplacer "atomique", mais j'ai une bonne idée de ce qui fait ou pas, selon moi, une bonne taille de commit.
Un commit pas trop gros
Un commit trop gros, c'est un commit qui regrouperait plusieurs fonctionnalités en un seul gros commit, son message pourrait être de ce genre :
Feature : ajout de l'authentification forte avec une app d'authenticator
J'ai aussi corrigé un bug sur le mot de passe perdu
J'en ai profité pour mettre à jour le framework
Généralement, les développeurs ne vont pas naturellement créer de gros commits, mais ça peut être une pratique de l'équipe de fusionner tous les commits d'une branche quand elle est terminée.
Dans Github par exemple on a le bouton "Squash and merge", qui permet de regrouper tous les commits d'une Pull Request en un seul avant de merger la branche. Utilisé à tort ça peut produire l'effet d'un commit trop gros.
Pourquoi c'est pas terrible ? Si plus tard on veut dissocier le commit, par exemple avec le commit ci-dessus, on voudrait juste annuler la mise à jour du framework, ça sera plus compliqué. Ça rend aussi l'historique plus concis, mais moins lisible.
Des commits trop petits
Inversement, trop découper les commits peut être aussi problématique même partant d'une bonne intention, par exemple, cette liste de commits très classique :
- 1 - Ajout de l'authentification avec une app d'authenticator
- 2 - Modification après code review : ajout de log en cas d'erreur
- 3 - Correction des coding standards pour l'intégration continue
- 4 - Mise à jour de la documentation
Au départ, découper un maximum peut paraitre une bonne idée, comme m'a dit un développeur :
Ça aide à voir le cheminement de pensée du développeur pendant qu'il a travaillé sur sa feature.
Pour moi c'est une fausse bonne idée, d'abord on n'a pas besoin de savoir a posteriori comment un dev a construit sa feature, chaque développeur a des méthodes différentes d'un autre. On arrive donc à un historique des commits très hétérogène.
Mais le plus gros problème, c'est que tout ces commits sont interdépendants, aucun ne peut être récupéré tout seul :
- Le commit 1 n'est pas complet, la fonctionnalité a été modifiée par le commit 2.
- Sans le commit 3, l'intégration continue plante.
- Le commit 4 n'a aucun sens sans la feature qu'il documente.
Donc si on veut faire une opération sur l'historique, par exemple enlever la feature qui ne doit pas être présente quand on prépare une branche de release, c'est encore une fois compliqué. Et à mon avis ça complexifie aussi la lisibilité de l'historique de commit.
La bonne taille du commit
Pas trop petit, pas trop gros :
- Le commit se suffit à lui même, il n'a pas besoin d'autres commits pour fonctionner. Quand on est face à des grosses fonctionnalités à développer, on ne va pas faire un seul gros commit qui représente des semaines de développement bien sûr, il s'agira de bien découper la fonctionnalité en un ensemble de sous fonctionnalités.
- Le commit ne concerne qu'une seule chose bien distincte : une fonctionnalité, un fix de bug, etc.
- Le commit a un message explicite, sur lequel on ne pourra pas se tromper en lisant l'historique.
Bien sûr, il y a des exceptions, et de temps en temps on est obligé de sur-découper ou de regrouper des commits, mais je pense que c'est une bonne pratique en général qui peut être appliquée la plupart du temps.
Cette pratique oblige de revenir modifier des commits souvent. On utilisera principalement git commit --amend (ajouter du code au dernier commit), git commit --fixup (ajouter du code à un commit précédent) et le rebase interactif.
Pour nous aider : Gitmoji ✨
Pour aider les développeurs à faire des commits interdépendants, avec un joli message de commit, nous utilisons depuis un moment Gitmoji sur tous nos projets. C'est une manière de structurer tout les commits en mettant un emoji selon le type du commit, et de forcer le développeur à se poser pour réfléchir à un message de commit compréhensif, généralement ça aide naturellement à mieux découper.
Nous utilisons aussi gitmoji-cli pour faire des jolis commits directement depuis la ligne de commande.
