Collaborer sur une forge
Demandes de fusion, stratégies d'intégration, branches protégées.
La demande de fusion n'existe pas dans Git : c'est une notion de forge. Techniquement, elle propose de fusionner une branche dans une autre — et ajoute tout ce que Git ne fait pas : revue, discussion, exigences de contrôles.
Trois façons d'intégrer, trois historiques
| Stratégie | Ce qui arrive sur main | Prix |
|---|---|---|
| Commit de fusion | tous les commits, plus un commit à deux parents | historique fidèle, mais dense |
| Écrasement (squash) | un seul commit | historique lisible, granularité perdue |
| Rebase | les commits, rejoués à la suite | historique linéaire, empreintes changées |
L'écrasement est le plus répandu, et son défaut se paye plus tard : quand
git bisect désigne un commit qui contient trois jours de travail, il reste
beaucoup à chercher. C'est un arbitrage entre lisibilité immédiate et capacité de
diagnostic — pas une bonne pratique universelle.
La règle qui aide à trancher : une demande de fusion doit faire une seule chose. Alors l'écrasement ne perd rien, parce qu'il n'y avait qu'une chose à raconter.
Protéger une branche
Sur main, une forge sait exiger : une revue approuvée, des contrôles au vert,
une branche à jour, des commits signés, et interdire le push forcé.
Ces règles s'appliquent à tout le monde, administrateurs compris — sinon elles ne protègent que ceux qui les respectaient déjà. L'interdiction du push forcé est la plus importante : c'est elle qui rend impossible la réécriture d'historique partagé de la règle d'or.
Exiger n'est pas obtenir
Rendre une revue obligatoire produit des approbations de complaisance si l'équipe n'a pas le temps de relire. Exiger des contrôles au vert produit des relances jusqu'à ce que ça passe, si les tests sont instables. C'est la mécanique décrite dans Bloquer n'est pas sécuriser : une règle contournable en pratique donne une sécurité de façade, plus dangereuse que l'absence de règle, parce qu'on croit être protégé.
CODEOWNERS
# fichier CODEOWNERS
/src/lib/quiz.ts @equipe-securite
/content/docs/ @equipe-pedagogie
/.github/workflows/ @equipe-plateformeLa forge convoque automatiquement les bonnes personnes selon les fichiers touchés. C'est ce qui évite les deux extrêmes : tout le monde relit tout — donc personne ne relit —, ou une seule personne relit tout et devient le goulet.
Placer src/lib/quiz.ts sous la responsabilité de l'équipe sécurité est un
exemple concret : c'est le module qui garantit que les réponses de quiz ne
quittent pas le serveur.
Le piège classique
« Branche à jour avant fusion » semble prudent, et devient ingérable sur un dépôt actif : chaque fusion périme toutes les autres demandes, qui doivent se remettre à jour, ce qui relance tous leurs contrôles. Sur un dépôt à vingt demandes ouvertes, l'exigence coûte plus qu'elle ne rapporte — d'où les files de fusion, qui testent l'intégration à la place des humains.
Réponse unique
Quel est le coût principal de l'intégration par écrasement (squash) ?
Indice · Que devient un bisect qui tombe sur un commit de trois jours de travail ?
[ METTRE EN PRATIQUE ]
Protéger une branche sans bloquer l'équipe
3 étapes · 30 min · 140 XP
[ CETTE LEÇON DANS LES PARCOURS ]
- Fondamentauxétape 11 / 18suivant — Diagnostiquer avec Git →
- Ingénieur DevOpsétape 11 / 23suivant — Les permissions Unix →