Git en équipe : revue de code et pull requests

Quand tu utilises Git seul·e, la vie est simple : tu fais tes commit, tu push, personne d'autre ne touche au code. Mais dès qu'on est plusieurs sur le même projet, tout change. Deux personnes qui modifient le même fichier en même temps, du code non terminé qui bloque celui des autres, des versions qui divergent : sans méthode, c'est le chaos. Ce cours porte sur cette méthode, celle qui permet à une équipe de contribuer à une même base de code de façon fluide et sûre.

Le point de départ est le dépôt distant partagé (sur GitHub, GitLab...) : c'est la référence commune, la source de vérité que toute l'équipe synchronise. Chacun·e a une copie locale, travaille dessus, puis renvoie ses modifications vers ce dépôt central. Toute la difficulté, et tout l'art du travail en équipe, consiste à coordonner ces allers-retours pour que les contributions de chacun s'intègrent sans écraser celles des autres.

Le principe fondateur : ne jamais travailler directement sur main

La règle d'or de la collaboration : on ne code jamais directement sur la branche principale (main). Cette branche représente la version stable, celle qui part en production. Chaque nouvelle fonctionnalité ou correction se développe sur une branche séparée, à l'écart, puis n'est intégrée à main qu'une fois terminée et validée. Ainsi, main reste toujours fonctionnelle, et le travail en cours de chacun n'interfère pas avec celui des autres.

Une branche est une ligne de développement indépendante : une copie du projet sur laquelle tu peux travailler sans affecter les autres branches. Tu crées une branche pour une fonctionnalité, tu y fais tes commits en toute tranquillité, et pendant ce temps main et les branches des collègues restent intactes. C'est le mécanisme central de la collaboration.

# Créer une branche ET s'y placer, en une commande
git switch -c feat/formulaire-contact

# (équivalent plus ancien, encore très courant)
git checkout -b feat/formulaire-contact

# Lister les branches (l'étoile marque celle où tu es)
git branch

# Revenir sur main
git switch main

git switch -c nom-de-branche crée une nouvelle branche et t'y positionne aussitôt. À partir de là, tous tes commits vont sur cette branche, sans toucher à main. On appelle ces branches de travail des branches de fonctionnalité (feature branches). Le nom de la branche doit décrire son objet : une convention répandue préfixe par le type, comme feat/ pour une fonctionnalité ou fix/ pour une correction.

Pourquoi isoler le travail

• Pas d'interférence : ton travail en cours ne casse pas celui des autres, et inversement.
• main reste stable : la branche principale est toujours dans un état fonctionnel, prête à déployer.
• Travail en parallèle : chacun avance sur sa branche, les fonctionnalités progressent simultanément.
• Point de validation : la branche est l'unité qu'on relit et qu'on teste avant de l'intégrer.

Le travail en équipe suit un enchaînement standard, le même à chaque contribution. Le maîtriser, c'est ne plus jamais se demander « par où je commence ? ». Voici le cycle complet, du départ à l'intégration.

# 1. Partir d'une base à jour
git switch main
git pull                          # récupère les derniers changements de l'équipe

# 2. Créer sa branche de travail
git switch -c feat/bouton-partage

# 3. Travailler : coder, puis committer par petites étapes
git add .
git commit -m "feat: ajoute le bouton de partage"

# 4. Envoyer sa branche sur le dépôt distant
git push -u origin feat/bouton-partage

# 5. Ouvrir une pull request sur GitHub (voir chapitre suivant)

Cinq étapes, toujours dans cet ordre. On commence toujours par mettre à jour main avec git pull, pour partir des derniers changements de l'équipe et minimiser les conflits futurs. On crée sa branche, on travaille en committant par petites étapes cohérentes, puis on pousse la branche sur le dépôt distant avec git push -u origin. La dernière étape, l'ouverture de la pull request, se fait sur l'interface de GitHub.

Une pull request (PR sur GitHub, merge request ou MR sur GitLab) est une demande d'intégration : tu proposes de fusionner ta branche dans main, et tu invites l'équipe à examiner ton travail avant de l'accepter. C'est bien plus qu'un simple bouton « fusionner » : c'est un espace de discussion autour de tes modifications, où l'on relit ton code, où l'on commente, et où des vérifications automatiques se lancent.

Une bonne description de PR

Une PR n'est pas qu'un tas de code : c'est un message à tes relecteur·euses. Une bonne description leur fait gagner un temps précieux et augmente tes chances d'être accepté·e vite. Elle répond à trois questions :

• Quoi ? Ce que fait la PR, en une ou deux phrases claires.
• Pourquoi ? Le besoin ou le problème résolu (souvent un lien vers un ticket).
• Comment tester ? Les étapes pour vérifier que ça marche, ou une capture d'écran.

## Quoi
Ajoute un bouton de partage sur les pages d'article.

## Pourquoi
Demande du ticket #142 : permettre le partage sur les réseaux sociaux.

## Comment tester
1. Ouvrir n'importe quel article
2. Cliquer sur le bouton "Partager"
3. Vérifier que le menu de partage s'affiche

Les vérifications automatiques (CI)

Quand tu ouvres une PR, une intégration continue (CI) se déclenche souvent automatiquement : elle lance les tests, vérifie le style du code (linter), contrôle que tout compile. Ces vérifications s'affichent directement sur la PR, avec une coche verte si tout passe ou une croix rouge sinon. Une PR dont la CI échoue ne doit pas être fusionnée : c'est un garde-fou qui empêche le code cassé d'atteindre main. On approfondit ce sujet dans le cours Tuto CI pour GitHub.

La revue de code (code review) est le moment où une autre personne relit tes modifications avant leur intégration. C'est l'une des pratiques les plus précieuses du développement : elle attrape des bugs, améliore la qualité, partage la connaissance dans l'équipe, et fait progresser autant celui qui relit que celui qui est relu. Pour un·e dev junior, participer aux revues est l'un des meilleurs accélérateurs d'apprentissage.

Quand tu relis le code d'un·e autre

• Comprends l'intention avant de commenter : lis la description de la PR.
• Cherche l'essentiel : bugs, cas oubliés, problèmes de sécurité, avant les détails de style.
• Sois bienveillant·e et précis·e : commente le code, jamais la personne ; propose plutôt qu'ordonner.
• Distingue le bloquant du souhaitable : « ceci provoque un bug » n'est pas « je préférerais ce nom ».

Au terme de sa relecture, le·la relecteur·euse rend un verdict : approuver (la PR peut être fusionnée), demander des changements (des points à corriger avant fusion), ou simplement commenter. Tu croiseras l'abréviation LGTM (« Looks Good To Me », « ça me va »), qui signale une approbation. Un bon commentaire de revue explique pourquoi, pas seulement quoi changer.

Quand c'est ton code qui est relu

Recevoir une revue peut piquer l'ego au début, mais c'est un cadeau, pas une critique personnelle. Quelques réflexes : ne prends pas les remarques pour toi (on parle du code, pas de toi), remercie pour les retours, réponds à chaque commentaire (en corrigeant ou en expliquant ton choix), et n'hésite pas à discuter quand tu n'es pas d'accord, arguments à l'appui. Une revue est un dialogue, pas un jugement.

Un conflit de fusion (merge conflict) survient quand deux branches ont modifié la même partie d'un fichier de façon différente. Git, incapable de choisir tout seul quelle version garder, s'arrête et te demande de trancher. C'est intimidant la première fois, mais ce n'est ni une erreur ni une catastrophe : c'est une étape normale du travail à plusieurs, qui se résout méthodiquement.

<<<<<<< HEAD
const titre = "Bienvenue sur notre site";
=======
const titre = "Bienvenue chez nous";
>>>>>>> feat/nouveau-titre

Git marque le conflit avec des balises. Entre <<<<<<< HEAD et ======= se trouve ta version (la branche courante) ; entre ======= et >>>>>>> se trouve la version de l'autre branche. Résoudre le conflit, c'est décider quoi garder : ta version, l'autre, ou une combinaison des deux, puis supprimer toutes les balises pour ne laisser que le code final voulu.

Les étapes de résolution

# 1. Git t'annonce le conflit lors d'un merge ou d'un pull
git status                   # liste les fichiers en conflit

# 2. Tu ouvres chaque fichier, tu choisis le bon code, tu retires les balises

# 3. Tu marques le conflit comme résolu
git add fichier-resolu.js

# 4. Tu finalises la fusion
git commit                   # (ou 'git merge --continue')

La marche à suivre est toujours la même : git status liste les fichiers en conflit, tu les ouvres et choisis le code final en supprimant les balises, puis git add marque chaque fichier comme résolu, et un commit finalise la fusion. Les éditeurs modernes comme VS Code affichent des boutons (« accepter la version actuelle / entrante ») qui rendent l'opération très visuelle. Rien de magique : tu décides, ligne par ligne, ce que devient le fichier.

En équipe, ton historique Git n'est plus seulement le tien : c'est une documentation partagée que tes collègues (et toi-même dans six mois) devrez relire pour comprendre l'évolution du projet. Des commits soignés et des branches bien nommées transforment cet historique en récit clair plutôt qu'en fouillis illisible.

Des commits atomiques et bien nommés

Un bon commit est atomique : il fait une seule chose cohérente. Évite le commit fourre-tout qui mélange une correction de bug, une nouvelle fonctionnalité et une reformulation. Un commit ciblé est plus facile à relire, à comprendre, et à annuler si besoin. Son message décrit ce que fait le changement, à l'impératif présent.

# ❌ Message vague et commit fourre-tout
git commit -m "modifs"

# ✅ Convention "commits conventionnels" : type: description
git commit -m "feat: ajoute le filtre par catégorie"
git commit -m "fix: corrige le calcul du total du panier"
git commit -m "docs: complète le README d'installation"

La convention des commits conventionnels, très répandue, préfixe le message par un type : feat (nouvelle fonctionnalité), fix (correction), docs (documentation), refactor, test, chore (tâches diverses). Ce petit préfixe rend l'historique scannable d'un coup d'œil et permet même de générer automatiquement des journaux de version. Ce n'est pas obligatoire, mais c'est un standard que beaucoup d'équipes adoptent.

Le récapitulatif des bonnes habitudes

• Commits atomiques : une intention par commit, un message clair à l'impératif.
• Branches nommées avec un préfixe de type : feat/, fix/, suivi d'une description courte.
• PR petites : plus facile à relire, à tester, à intégrer sans conflit.
• Un .gitignore à jour : jamais de node_modules, de .env ni de secrets dans le dépôt.
• Synchronise souvent avec main pour limiter les divergences.

Une fois ta PR relue, approuvée et sa CI au vert, vient l'intégration : la fusion de ta branche dans main. Sur GitHub, un bouton la déclenche, et l'on supprime généralement la branche de fonctionnalité juste après, son travail étant désormais dans main. Plusieurs stratégies de fusion existent, et il est utile de connaître les principales.

• Merge commit : conserve tous les commits de la branche plus un commit de fusion. L'historique reflète le déroulé réel.
• Squash and merge : condense tous les commits de la PR en un seul, propre, sur main. Très populaire pour un historique lisible.
• Rebase and merge : rejoue les commits de la branche à la suite de main, sans commit de fusion.

Pour un·e junior, retiens surtout le squash and merge, le plus courant : il transforme les nombreux petits commits de ta branche (« wip », « corrige typo », « re-corrige ») en un seul commit propre et descriptif sur main. L'historique de la branche principale reste ainsi net, une ligne par fonctionnalité. Le choix de la stratégie est une décision d'équipe ; l'important est la cohérence.

La branche protégée : le garde-fou

Pour garantir que main reste toujours saine, les équipes activent la protection de branche sur GitHub. Cette configuration interdit techniquement de pousser directement sur main et impose des conditions avant toute fusion : au moins une revue approuvée, une CI au vert, parfois une branche à jour. C'est ce qui rend les bonnes pratiques du cours non plus optionnelles mais obligatoires : impossible de contourner la revue ou de casser main par mégarde.