Pourquoi `main` est sacré

« Main est toujours vert » signifie une chose : à tout moment, la branche main est déployable en production. Pas « fonctionne en grande partie », pas « fonctionne si vous savez quels commits ignorer » — déployable. Maintenant. Sans intervention manuelle.

C'est une barre plus haute que la plupart des équipes ne le réalisent. Cela signifie que chaque commit sur main a passé les tests automatisés, a été révisé par un humain et ne dépend pas de travaux incomplets d'une autre branche. Cela signifie que vous pouvez déployer le vendredi à 16 h sans anxiété, parce que main n'est pas un travail en cours — c'est le produit fini à chaque commit.

Le mécanisme qui applique cela est l'intégration continue (CI). Chaque PR exécute la suite de tests, le linter et le vérificateur de types avant de pouvoir fusionner. Si une vérification échoue, la PR est bloquée. L'ingénieur corrige le problème sur sa branche — pas sur main, pas après la fusion, pas « plus tard ». La CI est le gardien qui garantit que main ne se dégrade jamais.

Les équipes sans cette discipline se retrouvent régulièrement dans un état où main est cassé et personne ne sait laquelle des cinq dernières fusions en est la cause. À ce moment-là, toute l'équipe est bloquée — ils ne peuvent pas tirer du nouveau code, ne peuvent pas démarrer de nouvelles branches à partir d'un état fonctionnel et ne peuvent pas déployer. Le coût d'un main rouge n'est pas le problème d'un ingénieur. C'est le problème de toute l'équipe, qui s'aggrave à chaque minute où il reste cassé.

Les règles de protection de branche sont l'application automatisée de « main est toujours vert ». Chaque plateforme majeure d'hébergement Git — GitHub, GitLab, Bitbucket — les prend en charge, et elles devraient être configurées dès le premier jour de tout projet sérieux.

Les trois règles qui comptent le plus :

• Révisions de PR obligatoires. Aucun push direct sur main. Chaque modification passe par une PR et au moins une approbation. Cela attrape l'impulsion « je vais juste pousser cette correction rapide » qui représente une part disproportionnée des incidents de production.
• Vérifications de statut obligatoires. La CI doit passer avant la fusion. Tests, linting, vérification de types — tout ce que votre pipeline exécute. Une vérification échouée bloque le bouton de fusion. Pas de contournements, pas de « je vais le corriger dans le prochain commit ».
• Historique linéaire. Exiger que les branches soient à jour avec main avant la fusion (rebase ou file d'attente de fusion). Cela empêche la situation où deux PR passent chacune la CI individuellement mais cassent lorsqu'elles sont combinées — parce que chaque PR est testée contre l'état actuel de main, pas un instantané obsolète.

Certaines équipes résistent aux règles de protection parce qu'elles semblent être une friction. Elles sont une friction — une friction intentionnelle qui empêche la classe d'erreurs la plus coûteuse. Configurer ces règles prend cinq minutes. Se remettre d'un force-push qui écrase le travail d'un coéquipier prend des heures, plus les dommages à la confiance. Le calcul n'est pas serré.

Lorsqu'un déploiement casse la production, les ingénieurs font face à un choix : corriger en avant ou annuler. L'instinct est presque toujours de corriger en avant — trouver le bogue, écrire un correctif, le pousser. Mais cet instinct est faux sous pression.

Une annulation est une seule commande qui annule proprement un commit connu :

git revert abc123f
# Creates a new commit that undoes abc123f
# Main is green again in minutes

L'alternative de correction de panique ressemble à ceci : un ingénieur penché sur son clavier à 23 h, écrivant du nouveau code sous pression, sautant les tests parce que « c'est juste une correction d'une ligne », poussant directement sur main parce que « nous n'avons pas le temps pour une PR ». Cette correction d'une ligne introduit un deuxième bogue 40 % du temps, parce que le code écrit sous adrénaline est du code écrit sans contexte complet.

La règle est simple : annuler d'abord, corriger plus tard. Remettre main au vert immédiatement — cela débloque toute l'équipe et arrête l'hémorragie. Ensuite, sans pression, écrivez une correction appropriée sur une branche avec des tests, une révision et la CI. La correction est livrée une heure ou un jour plus tard, mais elle est livrée correctement.

Les annulations donnent l'impression d'admettre un échec. Ce n'est pas le cas. Elles sont le chemin le plus rapide vers un état fonctionnel, et elles laissent le commit original dans l'historique comme documentation de ce qui s'est mal passé. Une équipe qui annule rapidement est une équipe qui livre avec confiance, parce que le coût d'un mauvais déploiement est de quelques minutes d'arrêt plutôt que des heures de lutte contre l'incendie.