GitHub : collaboration et Pull Requests

🎯 Objectif : À la fin de ce chapitre, tu sauras collaborer efficacement via GitHub — remotes, Pull Requests, code review et workflows d’équipe. ⏱️ Durée estimée : 50 minutes | Niveau : Intermédiaire

Tu sais committer, brancher, merger. Mais tant que ton code reste en local, tu travailles en solo. GitHub transforme Git en outil de collaboration. C’est là que les branches deviennent des Pull Requests, que les reviews remplacent les emails, et que le code avance à plusieurs sans se marcher dessus.

Pourquoi c’est important

Dans une équipe, personne ne push directement sur main. Le workflow standard passe par des Pull Requests (PR) : tu proposes tes changements, un collègue les relit, et on merge ensemble. Ce processus évite les régressions, partage les connaissances et maintient la qualité.

🔥 Cas réel : Une startup SaaS de 15 développeurs a réduit ses bugs en production de 40% simplement en imposant une review obligatoire sur chaque PR. Pas de nouvel outil, pas de process lourd — juste un deuxième regard systématique avant chaque merge.

GitHub n’est pas le seul (GitLab, Bitbucket existent), mais c’est le standard de l’industrie. Plus de 100 millions de développeurs l’utilisent. Si tu bosses en DevOps, tu vas le croiser partout.

💡 Tip DevOps : Configure les branch protection rules sur main dès le jour 1. Ça force la review et les checks CI avant tout merge. C’est gratuit et ça t’évitera des catastrophes.

Comprendre le workflow collaboratif

Le workflow GitHub repose sur trois concepts clés :

Les remotes — Un remote est un dépôt distant. Par convention, origin pointe vers ton dépôt GitHub. Si tu contribues à un projet externe, tu ajoutes un remote upstream vers le repo original.

Les Pull Requests — Une PR est une demande de fusion d’une branche vers une autre. Elle contient un diff visuel, un espace de discussion, des checks CI automatisés et un processus de review. C’est le cœur de la collaboration.

Les forks — Un fork est une copie complète d’un dépôt dans ton compte. C’est le mécanisme pour contribuer à un projet dont tu n’es pas collaborateur. Tu forks, tu branches, tu push sur ton fork, puis tu ouvres une PR vers le repo original.

Le cycle typique en équipe ressemble à ça :

1. Tu crées une branche depuis main
2. Tu codes et commites
3. Tu push ta branche sur GitHub
4. Tu ouvres une Pull Request
5. Un collègue review ton code
6. Tu intègres les retours
7. On merge — la branche est supprimée

⚠️ Attention : Ne confonds pas git pull et Pull Request. git pull est une commande locale (fetch + merge). Une Pull Request est un mécanisme GitHub de collaboration. Deux choses totalement différentes malgré le nom.

Commandes essentielles

Pour connecter ton repo local à GitHub, tu dois configurer un remote et pousser ton code. Voici comment initialiser un projet existant :

cd mon-projet
git remote add origin git@github.com:ton-user/mon-projet.git
git push -u origin main
# -u configure le tracking : après ça, "git push" suffit

Pour travailler au quotidien, tu alternes entre push et pull. Le flag --rebase sur le pull garde un historique linéaire plus lisible :

# Récupérer les changements du remote sans commit de merge
git pull --rebase origin main

# Pousser ta branche feature
git switch -c feature/auth-jwt
# ... travail, commits ...
git push -u origin feature/auth-jwt

Si tu contribues à un projet open source via un fork, tu dois gérer deux remotes. Voici le workflow complet :

# Clone ton fork, ajoute le repo original
git clone git@github.com:TON-USER/projet.git
cd projet
git remote add upstream git@github.com:ORIGINAL/projet.git

# Garde ton fork synchronisé
git fetch upstream
git switch main
git rebase upstream/main
git push origin main

Pour lier automatiquement tes PR aux issues, utilise les mots-clés dans tes messages de commit :

git commit -m "fix: gestion base vide closes #42"
# → Ferme automatiquement l'issue #42 au merge
# Mots-clés reconnus : closes, fixes, resolves

💡 Tip DevOps : Privilégie l’authentification SSH plutôt que HTTPS. Génère une clé avec ssh-keygen -t ed25519, ajoute-la dans GitHub Settings → SSH Keys. Plus besoin de tokens qui expirent.

Cas concret : workflow d’équipe DevOps

Imaginons une équipe de 4 personnes qui maintient une API de facturation. Voici leur workflow quotidien :

Le développeur crée une branche, code la feature, push et ouvre une PR avec une description structurée :

## Description
Ajout du endpoint /api/invoices/export pour l'export CSV.

## Changements
- Nouveau controller `invoice_export.py`
- Tests unitaires et d'intégration
- Documentation Swagger mise à jour

## Comment tester
1. `docker compose up -d`
2. `curl http://localhost:8080/api/invoices/export?format=csv`

## Checklist
- [x] Tests ajoutés
- [x] Doc mise à jour
- [ ] Review sécurité

Le reviewer examine le diff, commente les points à améliorer et approuve quand c’est prêt. Règles de l’équipe : PR de moins de 400 lignes, au moins une approval, tous les checks CI verts.

Le merge se fait en Squash and merge pour les features (un seul commit propre dans main) et en Merge commit pour les releases (on garde l’historique complet).

🔥 Cas réel : Cette même équipe utilise les GitHub Projects comme tableau Kanban avec 5 colonnes : Backlog → To Do → In Progress → In Review → Done. Chaque issue est liée à une PR. Quand la PR est mergée, la carte passe automatiquement en Done. Zéro mise à jour manuelle.

🧠 À retenir : Une bonne PR est petite et focalisée. Si ta PR fait plus de 500 lignes, découpe-la. Les grosses PR ne sont jamais bien reviewées — le reviewer fatigue et laisse passer des bugs.

Pièges fréquents

Pusher sur main directement — Sans protection de branche, n’importe qui peut pousser du code non reviewé en production. Active les branch protection rules immédiatement.

Laisser une PR ouverte trop longtemps — Une PR qui traîne 2 semaines accumule les conflits et devient impossible à reviewer. Vise un cycle de 24-48h max entre ouverture et merge.

Oublier de fetch avant de brancher — Si tu crées une branche depuis un main local obsolète, tu pars d’une base périmée et tu auras des conflits évitables.

Pour éviter ce dernier piège, prends le réflexe de toujours synchroniser avant de brancher :

git switch main
git pull --rebase
git switch -c feature/nouvelle-feature
# Tu pars d'un main à jour, pas d'une version vieille de 3 jours

Ne pas décrire sa PR — Une PR sans description force le reviewer à deviner le contexte. Prends 2 minutes pour expliquer le “pourquoi”, pas juste le “quoi”.

⚠️ Attention : git push --force sur une branche partagée écrase le travail des autres. Utilise --force-with-lease à la place : ça refuse le push si quelqu’un a poussé entre-temps.

# Dangereux sur branche partagée
git push --force  # ❌ écrase tout

# Safe : vérifie que personne n'a poussé
git push --force-with-lease  # ✅ refuse si conflit

Exercice pratique

Mets en place un workflow collaboratif complet :

1. Crée un repo sur GitHub et clone-le en local
2. Active les protections sur main : require PR, require 1 approval
3. Crée une branche feature/readme, ajoute un README.md détaillé
4. Push et ouvre une PR avec description, labels et checklist
5. Depuis un autre terminal (ou un second compte), review et approuve la PR
6. Merge en Squash et vérifie que main contient un seul commit propre

Bonus : Fork un repo open source, clone ton fork, crée une branche avec une correction de doc, et ouvre ta première PR vers le projet original.

🧠 À retenir : GitHub n’est pas juste un hébergeur de code. C’est un workflow de collaboration complet — branches protégées, PR avec review, issues liées, CI automatisée. Maîtriser ce cycle, c’est maîtriser le travail en équipe moderne. Le code n’est que le début : c’est la façon dont tu le partages qui fait la différence.