Git : Astuces et productivité #1

Dans ce premier article d’une série dédiée à git, j’aborde les commit atomiques.
Au programme de ladite série, Tips & tricks! : raccourcis, astuces et méthodologie (opinionated content!).

Commits atomiques

L’emploi des commits “atomiques” est encore peu courant, alors qu’il constitue la base de tout bon contrôle de version, en tant que concept comme en tant qu’outil, du commit history (avec tout ce qu’il a à offrir) à la code review.

📚 Un commit est dit atomique lorsque :

• Le changement qu’il apporte ne casse pas la cohérence du dépôt (compilation garantie et tests réussis).
• Il concerne une tâche et ne peut être découpé davantage sans enfreindre la règle précédente.
• Son message est précis et explique clairement le périmètre de son opération.

✌ Et les bénéfices sont aussi nombreux qu’évidents.

L’atomicité tend à réduire la taille des commits et à augmenter la fréquence des push : le code est sauvegardé plus régulièrement.

Le périmètre des commits atomiques, en plus d’être clairement défini, est généralement peu fragmenté à travers la codebase : les merge conflicts se raréfient et l’intention des autres développeurs se devine facilement.

L’historique des commits devient très pertinent : chaque entrée décrit précisément une modification; couplé à une convention de commit message, il joue pratiquement le rôle de changelog.

Les revues de code sont plus efficaces, réalisables “commit par commit” : le reviewer peut se concentrer sur chaque modification isolée. Chacune doit aussi être complète : quand c’est approprié, documentation et tests inclus.

Chaque modification apportée à un fichier devient légitime : aucun hors-sujet dans les git blame. Terminés les commits "fix bug" touchant à 9 fichiers dont 150 lignes de code et 7 fonctions ! Naturellement, cela s’accompagne aussi d’une meilleure chasse des régressions (manuelle, ou avec git bisect pour les lords 😁).

… etc!

💡 En pratique, cela se traduit principalement par l’augmentation de la fréquence des commits.

Une nouvelle fonctionnalité ? "feat(dashboard): add the step-by-step tutorial"
Des tests manquants sur une méthode ? "test(fcm): add tests for android payload factory"
Toutes les indentations passées de 2 à 4 espaces (à éviter 😁) ? "style: change indent. from 2 to 4 spaces"

Ces exemples de commits messages sont construits selon la convention suivante : conventional commits.
Ils sont composés :

• d’un type (feat, fix, test…)
• d’un scope optionnel (dashboard, fcm) faisait référence à une partie du code
• d’un message décrivant le changement apporté

Il n’y a aucun mal à faire de très petits commits, pourvu qu’ils respectent les règles citées en introduction. Il est de toute façon plus aisé de regrouper plusieurs commits en un seul, que d’en séparer un en plusieurs.
Dernier point positif : avec un historique clair, le ”squash pre-merge” (bouh! 🤮) n’a plus de raison d’être (mais en a-t-il déjà été autrement ? 😁).

Retrouvez-moi sur Twitter :
@VinceOPS