Les commandes Git à exécuter avant de lire le code

 (piechowski.io)
89 points par GN⁺ 2026-04-09 | 1 commentaires | Partager sur WhatsApp
  • Lorsqu’on découvre une nouvelle codebase, analyser l’historique Git pour comprendre la structure du projet et ses zones à risque permet de définir une stratégie d’exploration plus efficace
  • Repérer les fichiers les plus souvent modifiés sur l’année écoulée, puis croiser cette information avec la fréquence des bugs pour identifier le code à haut risque
  • Examiner la répartition des contributeurs et l’évolution de leur activité afin d’évaluer le bus factor, les lacunes de maintenance et les risques de perte de connaissances
  • Suivre le nombre de commits par mois pour observer l’évolution du rythme de développement et de la dynamique de l’équipe, puis évaluer la stabilité des déploiements via la fréquence des revert et hotfix
  • Ces cinq commandes constituent des outils concrets pour diagnostiquer rapidement l’état de santé d’un projet avant même d’ouvrir une seule ligne de code

Cinq commandes Git à lancer avant de lire le code

  • Lorsqu’on analyse une nouvelle codebase, l’idée est de diagnostiquer l’état de santé du projet à partir de l’historique Git avant même d’ouvrir des fichiers
    • L’historique des commits permet de voir qui a construit le projet, où les problèmes se concentrent et à quel point l’équipe déploie de manière stable

  • Qu’est-ce qui change le plus souvent ?

    • Commande : 
      git log --format=format: --name-only --since="1 year ago" | sort | uniq -c | sort -nr | head -20
    • Affiche les 20 fichiers les plus modifiés au cours des 12 derniers mois
    • Les fichiers en tête sont souvent ceux que l’équipe “n’ose pas toucher” : lorsque forte fréquence de changement (churn) et évitement de responsabilité se combinent, ils deviennent l’un des plus grands facteurs de charge de la codebase
    • Selon une étude de Microsoft Research (2005), les indicateurs basés sur la fréquence des changements prédisent mieux les défauts que les indicateurs de complexité
    • En croisant les 5 premiers fichiers avec la commande sur la concentration des bugs, on peut identifier comme risque maximal les fichiers souvent modifiés et souvent défaillants

  • Qui a construit ce code ?

    • Commande : 
      git shortlog -sn --no-merges
    • Classe les contributeurs selon leur nombre de commits
    • Si une seule personne dépasse 60 %, il existe un risque de bus factor
    • Si le principal contributeur n’a plus été actif au cours des 6 derniers mois, cela peut signaler un vide de maintenance
    • Si, sur 30 contributeurs, seuls 3 ont encore été actifs sur la dernière année, cela peut indiquer une rupture de transmission des connaissances due au turnover des développeurs
    • En revanche, une équipe qui utilise une stratégie de squash-merge peut voir les informations d’auteur biaisées en faveur de la personne qui fusionne ; il faut donc vérifier la stratégie de merge

  • Où les bugs se concentrent-ils ?

    • Commande : 
      git log -i -E --grep="fix|bug|broken" --name-only --format='' | sort | uniq -c | sort -nr | head -20
    • Extrait les 20 principaux fichiers liés aux bugs à partir des commits contenant des mots-clés associés aux corrections
    • En comparant cette liste avec celle de la fréquence des changements, on peut identifier comme code à haut risque les fichiers souvent modifiés et souvent cassés
    • La précision dépend de la qualité des messages de commit, mais cela reste très utile comme carte approximative de la densité des bugs

  • Le projet accélère-t-il ou stagne-t-il ?

    • Commande : 
      git log --format='%ad' --date=format:'%Y-%m' | sort | uniq -c
    • Le nombre de commits par mois permet de visualiser la tendance de l’activité
    • Un rythme régulier est le signe d’un projet en bonne santé
    • Si le nombre de commits est divisé par deux d’un mois à l’autre, cela peut signaler le départ de personnes clés
    • Une baisse continue sur 6 à 12 mois suggère une perte d’élan de l’équipe, tandis que des pics périodiques suivis de stagnation évoquent un modèle de release par lots
    • Dans un cas réel, un graphique de vélocité des commits a permis à un CTO de reconnaître que “c’était le moment où l’ingénieur senior était parti”
    • Ces données ont de la valeur en tant que données d’équipe plutôt que données de code

  • À quelle fréquence l’équipe est-elle en mode urgence ?

    • Commande : 
      git log --oneline --since="1 year ago" | grep -iE 'revert|hotfix|emergency|rollback'
    • Mesure la fréquence des revert et des hotfix
    • Quelques occurrences par an sont normales, mais si cela arrive toutes les deux semaines, c’est un signal de défiance envers le processus de déploiement
    • Cela peut révéler des problèmes plus profonds : tests instables, absence d’environnement de staging, procédures de rollback complexes
    • Si le résultat est de 0, soit l’équipe est stable, soit les messages de commit sont peu fiables
    • Les schémas de crise apparaissent clairement, et leur simple présence permet déjà d’évaluer le niveau de confiance

Conclusion

  • Ces cinq commandes peuvent être exécutées en quelques minutes et donnent une direction sur l’endroit où commencer à lire avant même d’ouvrir une seule ligne de code
  • Elles permettent, dès le premier jour, de remplacer une exploration au hasard par une analyse structurée du code centrée sur les zones à problème
  • Cette démarche correspond à la première heure d’un audit de codebase, avant de déboucher sur une semaine entière d’analyse

À lire aussi

1 commentaires

 
GN⁺ 2026-04-09
Réactions sur Hacker News

  • Partage d’exemples, avec Jujutsu, pour remplacer des commandes d’analyse de git
    On peut utiliser jj log pour voir les fichiers les plus modifiés sur l’année écoulée, les principaux contributeurs, les zones où les bugs se concentrent, la vitalité du projet, la fréquence des correctifs urgents, etc.
    La syntaxe est plus proche d’un langage de programmation que d’un script shell, mais il y a moins d’options à mémoriser

    • Pour moi, jujutsu ressemble au Nix des systèmes de gestion de versions
      Comme Nix, c’est élégant mais ça ajoute de la complexité
      Je l’ai utilisé quelques mois avant de revenir à git, parce que git est familier et disponible partout
    • Je ne comprends pas comment certains arrivent à retenir tous ces langages de script personnalisés
      Je suis déjà content quand je me souviens de la boucle sur les tableaux en jq, alors ce genre de syntaxe, ça ne me parle pas du tout
    • Les commandes jj comme les commandes git sont trop longues et complexes pour que j’aie envie de les retenir
      Si je dois les utiliser souvent, je les raccourcirais avec des alias
    • L’absence de commits ne veut pas forcément dire qu’un projet est mort, ça peut au contraire signifier qu’il est stable
      Par exemple, il existe une bibliothèque de génération de QR code sans mise à jour depuis 10 ans, et elle fonctionne parfaitement
      Il m’arrive de me demander s’il faudrait ajouter des commits inutiles juste pour faire plaisir aux bots
    • Je n’ai pas envie de programmer git, je veux juste finir mon travail
      C’est pour ça que je préfère les commandes UNIX en pipeline à des outils comme jujutsu
      C’est aussi la même logique qui me fait préférer Maven à Gradle

  • J’ai trouvé amusant que l’auteur parte du principe que les développeurs écrivent de bons messages de commit
    En réalité, c’est souvent du niveau de « changed stuff »
    Les gens comme moi, qui accordent de l’importance à l’historique des commits, sont minoritaires
    Les messages de commit générés par l’IA pourraient beaucoup aider sur ce point

    • C’est un problème de leadership. Un bon lead ou un bon CTO fixe clairement les attentes sur la qualité des messages de commit
    • Dans les équipes qui fusionnent en squashant les PR, la description de la PR devient le message de commit, donc la qualité est généralement meilleure
    • Avec un workflow squash & merge, c’est finalement le titre de la PR qui devient le message essentiel
      Les développeurs peuvent écrire ce qu’ils veulent dans les commits intermédiaires, puisqu’au final personne ne les lit
    • Dans notre équipe, on distingue les repos Core et Non-Core
      Pour les Core, review de PR et explications détaillées sont obligatoires ; pour les Non-Core, on peut expérimenter plus librement
      Sur les Core, il arrive que les messages de commit soient 20 fois plus longs que le code ; sur les Non-Core, on est au niveau de « hope this works »
    • Si les développeurs n’écrivent pas de vrais messages de commit, c’est surtout un problème de culture
      Dans notre entreprise, on l’exige les uns des autres

  • J’ai essayé ces commandes sur plusieurs bases de code, et les résultats ne reflétaient pas la réalité
    Par exemple, dans le résultat de git shortlog -sn --no-merges, la personne avec le plus de commits avait parfois déjà quitté l’entreprise
    Avoir beaucoup de commits ne signifie pas contribuer davantage

    • C’est pour ça que je préfère le squash-and-merge
      On garde les commits trop nombreux sur la branche de feature, puis on fusionne proprement dans la branche principale
    • Ce type de commande est utile pour diagnostiquer un projet en difficulté
      Sur une base de code ordinaire, ça produit souvent des résultats peu intéressants
    • Honnêtement, je me demande si l’auteur a vraiment exécuté ces commandes, on dirait un article écrit par un LLM
    • Si un workflow automatisé utilise les identifiants d’une seule personne, ça peut fausser complètement les statistiques
    • Moi aussi, j’ai un nombre écrasant de commits dans la base de code centrale d’une entreprise
      C’est parce que j’ai lancé le projet à partir de zéro, alors qu’aujourd’hui d’autres commitent plus souvent que moi

  • La remarque selon laquelle les fichiers les plus modifiés seraient ceux que les gens ont peur de toucher m’a paru intéressante

    • C’est un peu le paradoxe du « restaurant tellement bondé que plus personne n’y va »
    • En testant, j’ai vu que les fichiers les plus souvent modifiés étaient surtout des fichiers générés automatiquement ou des points d’entrée sans intérêt
    • Ce genre de commande demande des précautions
      Tirer des conclusions directement à partir du résultat peut au contraire donner l’air naïf
      En pratique, ça montre surtout sur quelles fonctionnalités on a travaillé pendant l’année écoulée
    • Regarder à la fois la churn (fréquence des changements) et la complexité est bien plus utile
      Les zones où les deux sont élevées sont les vraies zones à problème
      Quand ces zones s’accumulent, on commence à entendre qu’il faudrait « réécrire l’app depuis zéro »
    • Les fichiers que les gens redoutent sont ceux qui sont à la fois indispensables et complexes
      Tout le monde doit les modifier, mais ils sont si gros qu’ils deviennent difficiles à manipuler

  • J’ai créé dans git un alias summary qui affiche d’un coup le résumé des branches, le nombre de commits, le nombre d’auteurs, le nombre de fichiers, etc.
    L’idée vient de GitAlias/gitalias

    • Je me demande pourquoi c’est écrit comme une fonction dans .gitconfig ; faire simplement un script git-summary me semblerait plus simple
    • Le fait de retaper ces commandes à chaque fois donne vraiment l’impression d’un texte écrit par une IA ; en pratique, quelqu’un d’expérimenté les mettrait en alias pour les réutiliser
    • Le script est sympa, mais dans mon environnement je n’ai pas de commande comme log-of-count-and-email
    • Ce serait bien d’avoir une page man locale pour ce genre d’outil

  • Il faudrait ajouter une frontière de mot (\b) dans la regex
    Par exemple, le mot « bug » dans « debugger » peut produire de faux résultats
    La version corrigée ressemble à ceci
    git log -i -E --grep="\b(fix|fixed|fixes|bug|broken)\b" ...

    • Sur macOS, \b n’est pas pris en charge, donc il faut utiliser l’option d’expression régulière Perl -P au lieu de -E
      On peut alors écrire git log -i -P --grep="\b(...)\b"
    • Chez nous aussi, on utilise parfois le mot « rollback » dans un autre sens, donc un filtrage est nécessaire
    • Bonne remarque, c’est nettement plus précis

  • Sans squash-merge, la personne qui a le plus de commits peut au contraire être le développeur le plus brouillon
    J’en ai connu un comme ça : il modifiait sans arrêt le même fichier, avant d’être finalement licencié
    Le squash a l’avantage de masquer ce genre de problème

  • Les statistiques brutes de nombre de commits sont difficiles à croire
    Certains ne commitent que du code parfaitement testé, d’autres commitent très souvent ligne par ligne
    La valeur d’un seul commit peut varier d’un facteur 100 selon les personnes

    • Mais l’auteur cherchait surtout à observer les tendances d’évolution
      Le taux de variation a plus de sens que la valeur absolue

  • Cette approche de l’analyse rappelle « Your Code as a Crime Scene » d’Adam Tornhill
    Lien vers l’article original
    Cela évoque aussi le concept de Developer’s Legacy Index

    • J’aimais bien les premiers articles de Tornhill sur le C, ça fait plaisir de le revoir mentionné

  • L’article aurait gagné à montrer directement le résultat de chaque commande
    Des exemples de sortie auraient été plus convaincants que de simples explications

    • Moi aussi, j’ai trouvé que le texte avait un léger air d’article généré par IA, mais j’y ai quand même appris cinq commandes, donc ce n’est pas si mal