Workflow GitHub — branches, PR, CI

Ce guide montre comment installer un flux de contribution GitHub qui correspond à votre contexte, puis comment le durcir dès qu'une équipe ou une CI entre en jeu. On suppose que vous savez déjà utiliser Git en ligne de commande (branche, merge, tag, push).

Le principe directeur : calibrer la cérémonie sur le risque réel. Un flux trop lourd freine un projet solo ; un flux trop léger casse une collaboration.

Modèle de branches

Adoptez deux branches longues :

• une branche d'intégration (par ex. develop) où arrive le travail en cours ;
• une branche de release (par ex. main / master) qui reflète l'état livré.

Définissez la branche d'intégration comme branche par défaut du dépôt (Settings → General → Default branch) : les clones et les nouvelles PR pointeront dessus automatiquement.

Cas 1 — Contributeur unique (mono-décideur)

Quand une seule personne décide et fusionne, la PR n'apporte pas de garde-fou : elle ajoute surtout de la friction. Vous pouvez reporter l'intégration vers la release en merge fast-forward, sans PR.

git switch <branche-de-release>
git merge --ff-only <branche-integration>
git push

Le --ff-only garantit un historique linéaire : si le fast-forward est impossible, le merge échoue au lieu de créer un merge commit implicite. Complétez avec des commits explicites et des tags immuables pour vos versions.

Dans ce mode, il est légitime de ne pas protéger la branche de release. C'est un choix assumé, pas un oubli : la protection existe pour encadrer des contributeurs multiples et une revue — absents ici.

Cas 2 — Équipe et/ou CI : verrouiller la branche de release

Dès qu'un deuxième contributeur ou une CI apparaît, le besoin de garde-fous réapparaît (éviter un push destructeur, organiser la revue, bloquer sur des checks rouges). Basculez alors sur la protection de branche.

1. Sur GitHub, ouvrez le dépôt.
2. Settings → Branches.
3. Branch protection rules → Add rule.
4. Branch name pattern : le nom de votre branche de release.
5. Activez au minimum :
   • Require a pull request before merging — interdit les push directs, force le passage par PR.
   • Require approvals — impose une ou plusieurs revues avant merge (qualité, partage de connaissances).
   • Require status checks to pass — bloque le merge tant que les checks CI ne sont pas verts.
   • Require linear history — interdit les merge commits, conserve un historique linéaire.
   • Require conversation resolution — impose de résoudre les commentaires avant merge.
   • Do not allow bypassing the above settings — empêche tout contournement, y compris par les admins.
6. Create (ou Save changes).

Certaines protections et rulesets ne s'appliquent sur les dépôts privés qu'avec un plan GitHub payant (équipe/entreprise). Vérifiez votre plan si une règle ne prend pas effet.

Cas 2 (suite) — Le cycle de contribution avec PR

Une fois la protection active, le flux quotidien devient :

1. Créer une branche de fonctionnalité depuis l'intégration.

   git switch -c feat/ma-fonctionnalite <branche-integration>
   

2. Pousser et ouvrir une PR ciblant la branche d'intégration.
3. Laisser la CI s'exécuter (tests, lint, build) : le merge reste bloqué tant qu'un check est rouge.
4. Obtenir la ou les approbations requises et résoudre les conversations.
5. Fusionner la PR (privilégiez squash ou rebase pour préserver l'historique linéaire).
6. Reporter l'intégration vers la release via une PR dédiée, elle aussi soumise aux checks.

CI minimale

Un workflow CI se déclenche sur les événements push et pull_request. Gardez-le rapide et signifiant : installation des dépendances, lint, tests. Ce sont ces jobs que la règle Require status checks to pass rendra bloquants — nommez-les de façon stable, car GitHub référence les checks par leur nom.

Choisir son cas

Le point de bascule n'est pas le volume de code : c'est l'arrivée d'un second décideur ou d'une automatisation qui doit faire foi. Passez au cas 2 dès ce moment, sans attendre.