Branches et Pull Requests

Les branches existent parce que le vrai travail d'ingénierie ne se déroule pas en une seule séquence linéaire. À tout moment, une équipe de cinq personnes peut avoir trois fonctionnalités en cours, une correction de bogue en révision et un changement d'infrastructure en attente d'une fenêtre de déploiement. Sans branches, tout ce travail entrerait en collision dans un seul espace de travail partagé — des fonctionnalités à moitié terminées se brisant mutuellement, une correction de bogue expédiée accidentellement avec une fonctionnalité incomplète, des changements d'infrastructure s'emmêlant avec le code produit.

Une branche donne à chaque flux de travail son propre contexte isolé. Vous pouvez casser des choses, expérimenter, refactoriser agressivement — et rien de tout cela n'affecte vos coéquipiers jusqu'à ce que vous choisissiez explicitement de fusionner. Cette isolation est ce qui rend le travail parallèle possible sans surcharge constante de coordination.

Mais l'isolation n'est que la moitié de la valeur. Les branches réduisent également le coût de l'expérimentation. Vous voulez essayer un algorithme différent ? Créez une branche, prototypez, évaluez les performances. Si c'est plus rapide, fusionnez. Sinon, supprimez la branche. Coût total : zéro dommage à la base de code partagée, zéro bruit dans l'historique des commits, zéro retour en arrière nécessaire. Les équipes qui créent des branches librement essaient plus d'approches et trouvent de meilleures solutions. Les équipes qui traitent la création de branches comme lourde (ou la sautent entièrement en commitant sur main) expérimentent soit moins, soit dangereusement.

Une pull request est une proposition : « Voici ce que j'ai changé, voici pourquoi, et j'aimerais que quelqu'un y jette un œil avant la fusion. » Cela semble simple, mais cela représente un changement fondamental du contrôle qualité implicite vers l'explicite.

Sans PR, la révision de code est optionnelle, ad hoc et incohérente. Peut-être que quelqu'un regarde votre code avant qu'il ne soit expédié, peut-être pas. Peut-être qu'ils en regardent une partie. Peut-être qu'ils le regardent après qu'il soit déjà en production. Les PR font de la révision une porte — le code n'atteint pas main tant qu'au moins un autre ingénieur ne l'a pas lu, compris l'intention et approuvé l'approche.

Il ne s'agit pas de détecter des bogues (bien que cela le fasse). Il s'agit de propriété partagée. Lorsqu'une PR est révisée et approuvée, le changement n'est plus « le code de Sarah » — c'est le code de l'équipe. Le réviseur dit « Je comprends cela, je suis d'accord avec l'approche, et je suis à l'aise pour le maintenir. » Cette propriété distribuée signifie qu'aucun ingénieur ne devient un goulot d'étranglement ou un point de défaillance unique.

Les PR créent également un registre de décisions. La description explique le pourquoi, le diff montre le quoi, et les commentaires de révision capturent les compromis considérés. Trois mois plus tard, quand quelqu'un demande « pourquoi l'avons-nous construit de cette façon ? », la PR a la réponse — y compris les alternatives qui ont été discutées et rejetées.

La révision de code tourne mal quand elle devient un rituel de contrôle d'accès — un ingénieur senior bloquant les fusions avec des chicanes de style pendant que l'équipe attend. Ce n'est pas de la révision ; c'est un goulot d'étranglement déguisé en qualité.

Une bonne révision de code est une conversation entre pairs. Le travail du réviseur n'est pas de prouver qu'il en sait plus — c'est de demander « ai-je compris votre intention ? » et « avez-vous considéré ce cas limite ? » Les meilleurs commentaires de révision sont des questions, pas des directives. « Que se passe-t-il si cette liste est vide ? » enseigne plus que « Ajoutez une vérification null ici. »

Trois principes qui maintiennent la révision productive :

• Révisez l'approche, pas la syntaxe. Les linters détectent le formatage. Les humains devraient se concentrer sur la logique, l'architecture et le nommage — des choses que les machines ne peuvent pas évaluer.
• Répondez en heures, pas en jours. Une PR qui reste en révision pendant 72 heures est un travail bloqué. Si vous ne pouvez pas réviser aujourd'hui, dites-le — laissez quelqu'un d'autre s'en charger.
• Distinguez bloquant de non-bloquant. « Cela va planter en production » est un bloquant. « Je nommerais cette variable différemment » est une suggestion. Mélangez-les et chaque révision ressemble à un combat.

La culture de révision est également l'un des outils d'intégration les plus efficaces qu'une équipe possède. Un nouvel ingénieur lisant des révisions de PR apprend les modèles, préférences et erreurs passées de l'équipe plus rapidement que n'importe quelle documentation ne pourrait l'enseigner. L'archive de révision est un guide de style vivant.