2.7 KiB
2.7 KiB
Squash merge & distribution de la taille des PR — Astuces de Boris Cherny
Une synthèse des observations partagées par Boris Cherny (@bcherny), créateur de Claude Code, le 25 mars 2026.
| ← Retour à Claude Code Best Practice |  |
1/ 266 contributions en une seule journée — toujours squasher
Boris a partagé son graphe de contributions GitHub montrant 266 contributions le 24 mars — issues de 141 PR, toujours squashées, avec une médiane de 118 lignes par PR.
- Le squash merge fusionne tous les commits d'une branche en un seul commit sur la branche cible — l'historique reste propre et linéaire
- Une PR = un commit : il devient facile d'annuler des fonctionnalités entières et
git bisectest simplifié - Dans des workflows assistés par IA à haute vélocité (141 PR/jour), le squash est le choix pragmatique — les commits individuels « fix lint », « try this » au sein d'une branche ne sont que du bruit
2/ Distribution de la taille des PR — garde des PR petites
Boris a partagé la distribution des tailles sur ces 141 PR, totalisant 45 032 lignes modifiées (ajouts + suppressions) :
| Métrique | Lignes (ajout+supp) | Signification |
|---|---|---|
| p50 | 118 | Taille médiane d'une PR — la moitié des PR faisaient 118 lignes ou moins |
| p90 | 498 | 90 % des PR faisaient moins de 500 lignes |
| p99 | 2 978 | Seule ~1 PR dépassait ~3 000 lignes |
| min | 2 | Plus petite PR — un correctif rapide de 2 lignes |
| max | 10 459 | Plus grosse PR unique — probablement une migration ou du code généré |
- Une médiane de 118 lignes signifie que la plupart des PR sont ciblées et relisables, même à 141 PR/jour
- La distribution est fortement asymétrique à droite — la grosse PR occasionnelle est inévitable (renommages massifs, migrations), mais la norme reste serrée
- Les petites PR réduisent le risque de conflit de merge, sont plus faciles à relire et se marient parfaitement avec le squash merge pour des annulations propres
