Comprendre le modèle de collaboration sur gitrust

Ce que tu vas comprendre

  • Expliquer pourquoi gitrust impose une review avant toute fusion sur main (Bloom 2)
  • Analyser les compromis entre petites PRs fréquentes et grosses PRs rares (Bloom 4)
  • Évaluer si le modèle de review obligatoire convient à un contexte donné (Bloom 5)

Le problème concret

Tu travailles seul sur une feature pendant deux semaines. La branche diverge, s'accumule. Quand tu ouvres enfin une PR, elle contient 800 lignes de diff. Personne dans l'équipe ne veut (ni ne peut) la reviewer sérieusement — le review se réduit à « ça a l'air bien, LGTM ». Le code est fusionné avec des bugs qui auraient été détectés si quelqu'un avait lu attentivement 50 lignes.

gitrust est conçu pour rendre ce scénario difficile et le modèle opposé — petites PRs fréquentes, review courte et sincère — naturel et peu coûteux.

L'analogie

Imagine un journal scientifique avec comité de lecture. Chaque article soumis est lu par deux relecteurs indépendants avant publication. Les articles courts et bien ciblés obtiennent des retours rapides et précis. Les articles de 80 pages avec 200 références prennent six mois et reviennent avec des commentaires superficiels.

La code review dans gitrust fonctionne exactement comme le comité de lecture : plus le changement proposé est petit et focalisé, plus la review est rapide, sincère et utile. L'auto-merge (fusionner sa propre PR sans review externe) est interdit pour la même raison qu'un auteur ne peut pas valider lui-même son propre article : le biais de l'auteur rend les erreurs invisibles.

Le modèle

flowchart TD
    subgraph "Philosophie gitrust"
        A[Issue tracée
avant tout travail]
        B[Branche courte
1 issue = 1 branche]
        C[PR petite
≤200 lignes idéalement]
        D[Review sincère
par au moins 1 pair]
        E[CI verte
avant fusion]
        F[Fusion dans main
historique propre]
    end

    A --> B --> C --> D --> E --> F
    F -->|Nouvelle issue| A

Trois principes structurants :

1. Toute modification passe par une PR

gitrust n'interdit pas le push direct sur main au niveau du protocole Git, mais le modèle de collaboration encourage systématiquement la PR : c'est le seul endroit où la CI est déclenchée, où la review est documentée, où l'issue est liée et fermée automatiquement.

Les équipes qui veulent appliquer cela strictement protègent la branche main dans les paramètres du dépôt (niveau Maintainer requis pour le push direct).

2. L'auto-merge est refusé par convention

gitrust ne force pas techniquement la review externe — un Owner peut fusionner sa propre PR. Mais la convention du projet, renforcée par l'outillage (assignation de reviewers, statut « En attente de review »), crée une pression sociale pour attendre une approbation externe.

L'exception acceptable : un dépôt solo où l'on est seul contributeur. Dans ce cas, la CI joue le rôle du reviewer.

3. La taille d'une PR est un signal de qualité

Taille du diff Signal Action recommandée
< 100 lignes Excellent Review en 5-10 min, commentaires précis
100-300 lignes Acceptable Review en 30 min, décomposer si possible
300-600 lignes Attention Décomposer en sous-tâches
> 600 lignes Problème Presque impossible à reviewer sérieusement

Alternatives et compromis

Trunk-based development sans PR

Certaines équipes poussent directement sur main (trunk) avec feature flags pour isoler les fonctionnalités en développement. Plus rapide, moins de friction, mais nécessite une discipline de test très forte et une culture de confiance élevée. Adapté aux petites équipes seniors avec une couverture de tests élevée.

GitFlow avec longues branches de release

GitFlow maintient des branches develop, release/*, hotfix/* avec des cycles de merge longs. Adapté aux logiciels avec releases versionnées (ex. bibliothèques), inadapté aux services web déployés en continu.

Le choix de gitrust

gitrust adopte une variante de trunk-based development avec PR courtes : pas de develop séparée, pas de longues branches de feature, mais une PR obligatoire même pour les petits changements. C'est le compromis entre la vitesse du trunk-based et la traçabilité des PRs.

Vérifier ta compréhension

  1. Un développeur propose une PR de 900 lignes modifiant le système d'authentification. Quelles questions lui poser pour l'aider à la découper ? (Bloom 2 — expliquer)

  2. Ton équipe travaille sur un projet open-source avec des contributeurs externes que tu ne connais pas. Quels mécanismes de gitrust utiliserais-tu pour maintenir la qualité du code sans bloquer les contributions ? (Bloom 4 — analyser)

Pour aller plus loin