Aller au contenu principal

Travailler à deux avec une Pull Request

Schéma

Séance en binôme

Cette séance se fait avec un binôme. Mettez-vous d'accord avec votre partenaire sur qui sera Étudiant A et qui sera Étudiant B avant de commencer : les instructions ci-dessous sont différentes pour chacun des deux rôles.

  • Collaborer à deux sur un même dépôt GitHub, chacun sur sa propre branche.
  • Ouvrir une Pull Request, la faire relire par son binôme, et la fusionner.
  • Vivre un premier conflit à deux, et le résoudre ensemble.

Petite vérification​

Avant de commencer, vérifiez si vous savez encore...

  1. créer une branche et basculer dessus
  2. fusionner une branche dans main
  3. citer les 3 balises que Git insère dans un fichier en conflit
📌 Réponse attendue

Notions théoriques​

Jusqu'ici, vous avez fusionné des branches directement en local, avec git merge. En équipe, on procède autrement : chacun pousse sa branche sur GitHub, puis ouvre une Pull Request (PR) — littéralement une "demande de fusion" — pour que quelqu'un d'autre relise le travail avant qu'il ne rejoigne main.

Pourquoi ne pas fusionner directement ?​

  • Relecture à quatre yeux : une erreur, un oubli, une faille de sécurité repérés avant qu'ils n'atteignent le code principal.
  • Discussion : la Pull Request porte des commentaires, ligne par ligne si besoin.
  • Historique clair : chaque fonctionnalité correspond à une PR identifiable, avec sa description et sa discussion associée.
info

Ce fonctionnement s'appelle le GitHub Flow : une branche par fonctionnalité, une Pull Request pour la faire relire et fusionner, puis suppression de la branche. C'est le workflow le plus répandu dans les équipes de développement professionnelles.

Le rôle de collaborateur​

Pour qu'une seconde personne puisse pousser des branches sur un dépôt, il faut l'ajouter comme collaborateur : sur GitHub, Settings → Collaborators → Add people.

Schéma

Le cycle d'une Pull Request​

  1. Créer une branche pour la fonctionnalité (git switch -c ma-fonctionnalite).
  2. Committer son travail localement.
  3. Pousser la branche sur GitHub (git push -u origin ma-fonctionnalite).
  4. Sur GitHub, cliquer sur Compare & pull request, rédiger un titre et une description claire.
  5. La personne désignée relit : elle commente, demande des changements, ou approuve.
  6. Une fois approuvée, la PR est fusionnée (bouton Merge pull request), puis la branche est supprimée.
  7. Chacun récupère la nouvelle version de main en local (git pull).

Exemple pratique — à réaliser en binôme​

Nous allons créer ensemble le site d'un club de lecture, club-lecture.

1. Mise en place (Étudiant A)​

Étudiant A crée le dépôt sur GitHub, avec un premier fichier :

mkdir club-lecture && cd club-lecture
git init
echo "<h1>Club de lecture</h1>" > index.html
git add index.html
git commit -m "Page d'accueil initiale"
git remote add origin git@github.com:etudiant-A/club-lecture.git
git push -u origin main

Sur GitHub : Settings → Collaborators → Add people, saisissez le nom d'utilisateur GitHub d'Étudiant B.

2. Rejoindre le dépôt (Étudiant B)​

Étudiant B accepte l'invitation reçue par email ou notification GitHub, puis clone le dépôt :

git clone git@github.com:etudiant-A/club-lecture.git
cd club-lecture

3. Travailler chacun sur sa branche​

Étudiant A, dans son dossier club-lecture :

git switch -c feature-programme
echo "<h2>Programme du mois</h2><p>Le Comte de Monte-Cristo</p>" >> index.html
git add index.html
git commit -m "Ajoute le programme du mois"
git push -u origin feature-programme

Étudiant B, dans son dossier club-lecture :

git switch -c feature-contact
echo "<h2>Nous contacter</h2><p>club-lecture@lycee.fr</p>" >> index.html
git add index.html
git commit -m "Ajoute la section contact"
git push -u origin feature-contact

4. Ouvrir les Pull Requests​

Chacun se rend sur la page GitHub du dépôt : un bandeau propose Compare & pull request pour la branche qu'il vient de pousser. Cliquez dessus, ajoutez un titre et une courte description, puis Create pull request.

5. Relire la Pull Request de l'autre​

Étudiant A relit la PR d'Étudiant B, et inversement : ouvrez l'onglet Files changed, lisez les lignes ajoutées (en vert), laissez au moins un commentaire, puis cliquez sur Review changes → Approve.

astuce

Un commentaire de relecture utile est précis et constructif : "Cette adresse email semble correcte" ou "Peut-être préciser les horaires de la permanence ?", plutôt qu'un simple "OK".

6. Fusionner​

Une fois approuvée, l'auteur de la PR (ou son binôme) clique sur Merge pull request, puis Delete branch. Faites-le pour les deux Pull Requests.

7. Se resynchroniser​

Chacun récupère la nouvelle version de main, qui contient maintenant les deux contributions :

git switch main
git pull
cat index.html
attention

Si les deux Pull Requests ont modifié la même ligne d'index.html, la seconde fusion signalera un conflit directement sur GitHub. GitHub propose alors de résoudre le conflit en ligne, ou vous pouvez le faire en local comme vu dans la séance précédente : git switch main, git pull, git switch feature-xxx, git merge main, résoudre, git push.

Test de mémorisation/compréhension​


Que permet une Pull Request, que ne permet pas un git merge direct en local ?


Pour qu'une autre personne puisse pousser des branches sur votre dépôt GitHub, que faut-il faire ?


Dans le GitHub Flow, où travaille-t-on pour une nouvelle fonctionnalité ?


Quelle commande envoie une branche locale vers GitHub pour la première fois ?


Que doit faire la personne qui relit une Pull Request avant de la fusionner ?


Que se passe-t-il si deux Pull Requests modifient la même ligne d'un même fichier ?


Que fait-on généralement à une branche juste après la fusion de sa Pull Request ?


TP pour réfléchir et résoudre des problèmes — en binôme​

Avec le même binôme, reproduisez le cycle complet vu dans l'exemple pratique, sur un nouveau projet.

Étape 1 — Créer le dépôt partagé (Étudiant A)​

Créez un dépôt site-association-sportive avec un fichier index.html contenant <h1>Association sportive du lycée</h1>, poussez-le sur GitHub, puis ajoutez Étudiant B comme collaborateur.

Étape 2 — Rejoindre le dépôt (Étudiant B)​

Clonez le dépôt sur votre machine.

Étape 3 — Deux branches, deux fonctionnalités​

  • Étudiant A : branche feature-horaires, ajoutant les horaires d'ouverture du gymnase.
  • Étudiant B : branche feature-inscription, ajoutant les modalités d'inscription.

Chacun committe et pousse sa branche.

Étape 4 — Pull Requests croisées​

Chacun ouvre sa Pull Request, puis relit celle de l'autre : au moins un commentaire, puis une approbation.

Étape 5 — Fusionner et se resynchroniser​

Fusionnez les deux Pull Requests (en gérant un éventuel conflit comme indiqué dans l'exemple pratique), supprimez les branches, puis vérifiez que chacun récupère bien, en local, les deux contributions réunies dans index.html.

Bonne pratique - Une Pull Request, une fonctionnalité

Gardez chaque Pull Request petite et centrée sur un seul sujet. Une PR qui mélange dix changements sans rapport entre eux est difficile à relire, et donc à approuver en confiance.

📌 Une solution