Workflow GitHub : fork, pull request et revue de code

Jusqu’ici, Git vivait sur votre machine. Mais la valeur d’un projet explose dès qu’on collabore — et c’est là que GitHub entre en scène. GitHub héberge votre dépôt, mais surtout il offre un rituel de collaboration éprouvé : on propose un changement, l’équipe le relit, on l’améliore, puis on l’intègre. Ce cycle — la pull request — est devenu le langage commun de millions de projets, du plus petit dépôt personnel aux plus grands logiciels libres. À la fin de ce tutoriel, vous saurez contribuer à un projet que vous ne possédez pas : le forker, proposer une pull request, et participer à une revue de code.

🎯 Ce que vous allez apprendre

• Distinguer clairement Git (l’outil) de GitHub (la plateforme).
• Vous authentifier correctement avec un jeton d’accès ou une clé SSH.
• Forker un dépôt, le cloner et configurer le dépôt amont (upstream).
• Créer une branche, pousser et ouvrir une pull request soignée.
• Mener et recevoir une revue de code constructive.
• Choisir la bonne stratégie de fusion côté GitHub et garder votre fork à jour.

🛠️ Ce que vous allez construire

Vous allez proposer une contribution au dépôt boutique-inventaire hébergé sur GitHub, comme si c’était le projet d’une autre personne : un fork, une branche feature/tri-alphabetique, une pull request documentée, puis le cycle complet de relecture jusqu’à la fusion. Vous repartirez avec un modèle mental réutilisable sur n’importe quel projet open source.

Prérequis

• Un compte GitHub (gratuit).
• Git installé et configuré (voir les bases de Git).
• Être à l’aise avec branches et commits.
• Niveau intermédiaire. ⏱️ Temps estimé : environ 55 minutes.

Étape 1 — Git n’est pas GitHub

La confusion est si répandue qu’il faut la lever d’emblée. Git est le logiciel de contrôle de version qui tourne sur votre machine ; il fonctionne parfaitement sans aucun compte ni connexion. GitHub est une plateforme en ligne qui héberge des dépôts Git et ajoute par-dessus des outils de collaboration : pull requests, revues, suivi des tickets, automatisations. On peut faire du Git sans GitHub, et il existe des alternatives à GitHub qui hébergent aussi des dépôts Git, comme GitLab, Bitbucket ou Gitea. GitHub reste toutefois la place de marché de référence du logiciel libre.

Retenez l’image : Git est le moteur, GitHub est l’un des garages où l’on gare et partage les voitures. Tout ce que vous avez appris localement reste valable ; GitHub ajoute simplement la dimension collective.

Étape 2 — S’authentifier : jeton ou clé SSH

Point qui bloque énormément de débutants : depuis le 13 août 2021, GitHub n’accepte plus le mot de passe de votre compte pour les opérations Git en HTTPS. Il faut s’authentifier autrement. Deux voies s’offrent à vous.

La première, en HTTPS, repose sur un jeton d’accès personnel (en anglais personal access token, ou PAT). On le génère dans les réglages développeur de GitHub ; les jetons « fine-grained » (à portée restreinte) sont recommandés car ils limitent précisément les dépôts et les droits accordés. Au moment où Git vous demande un mot de passe lors d’un push, vous collez ce jeton à la place.

La seconde, plus confortable à l’usage, repose sur une clé SSH. On la génère une fois, puis on ajoute la clé publique à son compte GitHub.

ssh-keygen -t ed25519 -C "awa@example.com"
cat ~/.ssh/id_ed25519.pub

L’algorithme ed25519 est celui que GitHub recommande aujourd’hui : court, rapide et sûr. Copiez le contenu affiché (la clé publique, jamais la privée) dans GitHub, et vos push et pull ne vous demanderont plus rien. Testez la connexion avec ssh -T git@github.com.

✅ Point d’étape — Une authentification fonctionnelle est la condition de tout le reste. Vérifiez-la : un git push de test ne doit plus échouer avec « Support for password authentication was removed ».

Étape 3 — Forker et cloner

Contribuer à un projet dont vous n’êtes pas membre suit un schéma précis : le fork. Forker, c’est créer votre copie personnelle du dépôt sur votre compte GitHub, sur laquelle vous avez tous les droits. Le bouton « Fork » de la page du projet s’en charge. Vous clonez ensuite votre fork sur votre machine.

git clone git@github.com:votre-compte/boutique-inventaire.git
cd boutique-inventaire

Votre clone connaît déjà un dépôt distant nommé origin : c’est votre fork. Mais il faut aussi pouvoir suivre le projet d’origine pour rester à jour. On l’ajoute comme second distant, par convention nommé upstream (« amont »).

git remote add upstream git@github.com:projet-original/boutique-inventaire.git
git remote -v

La commande git remote -v doit lister deux distants : origin (votre fork, en lecture/écriture) et upstream (le projet original, que vous suivrez en lecture). Cette double connexion est le cœur du modèle de contribution open source.

Étape 4 — Brancher, commiter, pousser

On ne travaille jamais directement sur main dans ce modèle : on crée une branche dédiée à la contribution. Cela garde votre proposition isolée et permet d’en mener plusieurs en parallèle.

git switch -c feature/tri-alphabetique
echo "function trierAlpha(stock) { return stock.sort((a, b) => a.nom.localeCompare(b.nom)); }" > tri-alpha.js
git add tri-alpha.js
git commit -m "Ajoute le tri alphabétique des produits"
git push -u origin feature/tri-alphabetique

L’option -u (pour upstream, à ne pas confondre avec notre distant upstream) lie votre branche locale à la branche distante : vos prochains git push et git pull sauront quoi faire sans argument. GitHub répond souvent par un lien direct pour ouvrir la pull request — pratique.

Étape 5 — Ouvrir une pull request soignée

Sur la page de votre fork, GitHub propose « Compare & pull request ». Une pull request (PR) demande au projet d’origine d’intégrer les changements de votre branche. Sa qualité conditionne sa rapidité d’acceptation. Soignez deux éléments : un titre clair et impératif (« Ajoute le tri alphabétique des produits »), et une description qui explique le quoi et surtout le pourquoi, avec, si pertinent, comment tester. Si la contribution répond à un ticket, liez-le : écrire Closes #12 dans la description fermera automatiquement le ticket 12 à la fusion.

Si votre travail n’est pas terminé mais que vous voulez un retour précoce, ouvrez une pull request en brouillon (draft) : elle signale clairement qu’elle n’est pas prête à fusionner, tout en permettant la discussion. Vous la marquerez « prête » plus tard.

Étape 6 — La revue de code

La revue est le cœur battant de la collaboration. Un relecteur parcourt votre diff et laisse des commentaires ligne par ligne, parfois sous forme de suggestions de code que vous pouvez accepter d’un clic. Au terme de sa lecture, il conclut par l’un de trois verdicts : Approve (c’est bon), Request changes (des modifications sont nécessaires), ou un simple Comment (remarques sans blocage).

Le point qui émerveille les débutants : répondre à une revue ne demande aucune manipulation compliquée. Vous corrigez en local, commitez, et poussez sur la même branche — la pull request se met à jour automatiquement avec vos nouveaux commits.

git switch feature/tri-alphabetique
echo "// gère le cas du stock vide" >> tri-alpha.js
git commit -am "Gère le tri d'un stock vide"
git push

Le relecteur voit aussitôt vos ajustements et peut résoudre les fils de discussion concernés. Côté étiquette, traitez chaque commentaire : appliquez-le, ou expliquez courtoisement pourquoi vous ne le faites pas. Une revue est un dialogue technique, jamais un jugement personnel.

✅ Point d’étape — Après un git push sur la branche de la PR, rechargez la page GitHub : vos nouveaux commits doivent apparaître dans l’onglet « Commits » de la pull request, et les vérifications automatiques (s’il y en a) se relancent.

Étape 7 — Fusionner, et garder son fork à jour

Une fois la PR approuvée, un mainteneur la fusionne via un bouton offrant trois stratégies, qu’il est bon de comprendre. Create a merge commit conserve tous vos commits et ajoute un commit de fusion : l’historique est fidèle mais ramifié. Squash and merge condense toute la PR en un seul commit sur la branche principale : idéal pour garder un historique propre quand la PR contenait des commits brouillons. Rebase and merge rejoue vos commits un par un sans commit de fusion : historique linéaire, mais chaque commit doit se tenir seul.

Après fusion, votre fork accuse un retard sur le projet d’origine, qui a avancé. Resynchronisez-le en récupérant l’amont puis en mettant à jour votre main local et distant.

git switch main
git fetch upstream
git merge upstream/main
git push origin main

Le bouton « Sync fork » de l’interface GitHub fait la même chose en un clic. Enfin, supprimez la branche fusionnée, devenue inutile, localement et sur votre fork — GitHub propose souvent un bouton « Delete branch » directement sur la PR fermée.

Aller plus vite avec la ligne de commande GitHub

L’outil officiel gh (GitHub CLI) permet de tout faire depuis le terminal, sans quitter votre éditeur. Après authentification unique, les contributions s’enchaînent en quelques commandes.

gh auth login
gh repo fork projet-original/boutique-inventaire --clone
gh pr create --title "Ajoute le tri alphabétique" --body "Trie les produits par nom."
gh pr checkout 42
gh pr review 42 --approve

Ces commandes reproduisent exactement le parcours précédent : forker et cloner, ouvrir une PR, récupérer la branche d’une PR pour la tester localement, et émettre une revue. Une fois adopté, gh fait gagner un temps précieux sur les contributions répétées.

Branches protégées et vérifications automatiques

Sur les projets sérieux, on ne fusionne pas n’importe comment dans main. Les responsables configurent des règles de protection de branche qui imposent des garde-fous : interdiction de pousser directement sur main, obligation d’au moins une revue approuvée avant la fusion, et réussite obligatoire des vérifications automatiques. Ces dernières, appelées status checks, sont des tâches déclenchées à chaque mise à jour de la pull request — exécution des tests, analyse du style de code, compilation du projet. Tant qu’une vérification échoue ou qu’une revue manque, le bouton de fusion reste désactivé.

Du point de vue du contributeur, cela change la façon de travailler : poussez tôt et souvent pour voir les vérifications tourner, lisez leurs journaux quand elles échouent, et corrigez avant de solliciter une revue humaine. Ce dispositif protège l’équipe entière contre les régressions : tout ce qui entre dans main compile, passe les tests et a été relu. Comprendre ce mécanisme vous rend immédiatement plus efficace sur n’importe quel projet collaboratif structuré.

🐞 Pièges fréquents

Travailler avec une connexion limitée

Le travail de fond reste local : forker une fois, puis brancher, commiter et résoudre les conflits hors ligne. Seuls le push, le fetch et l’ouverture de la pull request exigent une connexion — des opérations brèves que l’on regroupe. Une bonne pratique consiste à préparer toute sa contribution localement (plusieurs commits, historique nettoyé au besoin avec le rebasage interactif), puis à tout envoyer en une seule fois. Le clone superficiel (git clone --depth 1) reste utile pour les gros dépôts dont on ne veut pas tout l’historique.

✅ Récapitulatif

Vous savez désormais distinguer Git de GitHub, vous authentifier par jeton ou clé SSH, et dérouler le cycle complet de contribution : forker, cloner, ajouter le distant upstream, brancher, pousser, ouvrir une pull request documentée, mener la revue, puis fusionner avec la bonne stratégie et resynchroniser votre fork. Vous connaissez aussi gh pour accélérer le tout. C’est le savoir-faire qui ouvre les portes du logiciel libre et du travail en équipe. Reste un dernier domaine à apprivoiser pour travailler l’esprit tranquille : savoir réparer quand quelque chose tourne mal.

🧾 Aide-mémoire

💪 À vous de jouer

Forkez un petit dépôt public de votre choix (par exemple une liste « awesome » qui accepte les ajouts), créez une branche, ajoutez une ligne pertinente, poussez sur votre fork et ouvrez une pull request avec un titre et une description clairs. Observez le retour des mainteneurs.

gh repo fork OWNER/depot --clone
cd depot
git switch -c ajout-ressource
# éditer le fichier, ajouter votre ligne
git commit -am "Ajoute une ressource utile à la liste"
git push -u origin ajout-ressource
gh pr create --title "Ajoute une ressource utile" --body "Cette ressource complète la section X."

FAQ

Q : Quelle différence entre fork et clone ?
R : Le fork crée une copie du dépôt sur votre compte GitHub ; le clone télécharge un dépôt sur votre machine. On clone généralement son propre fork.

Q : Jeton d’accès ou clé SSH ?
R : Les deux fonctionnent. La clé SSH est plus confortable au quotidien (rien à retaper) ; le jeton fine-grained est pratique pour des droits restreints et temporaires.

Q : Merge, squash ou rebase à la fusion ?
R : Squash pour un historique propre à partir d’une PR brouillonne ; merge commit pour garder la trace fidèle ; rebase pour une ligne droite si chaque commit se tient seul.

Q : Dois-je rouvrir une PR après une correction ?
R : Non. Poussez vos commits sur la même branche : la PR existante se met à jour automatiquement.

Q : Comment garder mon fork synchronisé ?
R : git fetch upstream puis git merge upstream/main, ou le bouton « Sync fork » de GitHub.

Ressources

• Documentation GitHub (en français) : docs.github.com/fr
• GitHub CLI : cli.github.com
• Première contribution open source : le guide pas-à-pas pour devs juniors

Dans la même série

• Résoudre les conflits de fusion dans Git
• Annuler et réparer dans Git : reset, revert, reflog, stash

🔝 Retour au guide complet : Maîtriser Git et GitHub.