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

• 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