Imaginez qu'Emma et Lucas partagent maintenant l'accès au dépôt GitHub de mon-premier-site, tous deux avec les droits nécessaires pour y pousser des branches. Emma veut ajouter une courte section de contact sur la page d'accueil. Plutôt que de modifier main directement, elle va passer par une Pull Request, souvent abrégée en « PR ».

Ce qu'est réellement une Pull Request

Une Pull Request n'est pas une commande Git : c'est une fonctionnalité propre à GitHub (et à des plateformes équivalentes comme GitLab, sous un autre nom). Elle compare une branche source à une branche cible, affiche les différences, permet d'y laisser des commentaires ligne par ligne, et centralise tout l'historique de discussion autour d'un changement précis, avant qu'il ne soit fusionné.

L'intérêt principal : Emma peut travailler plusieurs jours sur sa section de contact, pousser plusieurs commits intermédiaires, sans jamais toucher directement à main. Lucas peut relire son travail avant qu'il n'affecte la version publique du site.

Emma crée sa branche

Depuis son propre dossier local, à jour avec main, Emma crée une branche dédiée à sa tâche.

Elle modifie index.html pour ajouter un court paragraphe de contact sous le titre, teste le résultat dans son navigateur, puis committe son travail comme d'habitude.

Pousser la branche sur GitHub

Sa branche n'existe encore que localement. Elle la pousse avec la même logique que pour main au guide 14, en adaptant simplement le nom de branche.

Ouvrir la Pull Request

Sur la page GitHub du dépôt, une bannière propose généralement, juste après un push de branche, de comparer et créer une Pull Request directement. Sinon, l'onglet « Pull requests » du dépôt permet d'en créer une manuellement, en choisissant la branche source (ajouter-section-contact) et la branche cible (main).

Emma remplit ensuite un titre et une description : ce qu'elle a changé, pourquoi, et comment elle a vérifié que ça fonctionne. Une bonne description fait gagner du temps à la personne qui va relire, en particulier si elle n'a pas suivi le développement au jour le jour.

Lucas relit la proposition

Lucas ouvre la Pull Request depuis son propre compte. GitHub affiche un onglet « Files changed », qui présente un diff : les lignes ajoutées en vert, celles supprimées en rouge, exactement comme vous l'avez déjà vu en local avec git diff dans les guides précédents, mais dans une interface web pensée pour la discussion.

Lucas peut laisser un commentaire directement sur une ligne précise, par exemple pour suggérer une reformulation, sans avoir besoin d'ouvrir son éditeur de code. Emma peut alors modifier son fichier localement, committer une correction, et la repousser sur la même branche : le commit supplémentaire s'ajoute automatiquement à la Pull Request déjà ouverte, sans qu'elle ait besoin d'en créer une nouvelle.

Fusionner une fois la review terminée

Quand Lucas est satisfait du résultat, il utilise le bouton de fusion proposé par GitHub, directement dans l'interface de la Pull Request. Selon les réglages du dépôt, plusieurs stratégies de fusion peuvent être proposées : une fusion classique, un « squash » qui regroupe tous les commits de la branche en un seul avant de fusionner, ou un rebase. Pour un petit projet comme mon-premier-site, une fusion classique convient très bien.

Après la fusion, la branche ajouter-section-contact peut être supprimée depuis GitHub, exactement comme vous l'avez fait localement au guide 11 après une fusion réussie. Emma et Lucas doivent ensuite chacun mettre à jour leur propre copie locale de main avec git pull, pour retrouver le changement sur leur ordinateur.

Bon réflexe

Gardez vos Pull Requests petites et centrées sur une seule tâche claire. Une PR qui modifie vingt fichiers pour cinq raisons différentes est presque impossible à relire sérieusement. Une PR qui ajoute une seule section de contact, comme celle d'Emma ici, se relit en quelques minutes.

Vérifiez que vous avez compris

Emma a ouvert sa Pull Request, mais Lucas n'a pas encore cliqué sur le bouton de fusion. Le changement d'Emma est-il déjà visible sur la branche main à ce moment ?

Non. Tant qu'une Pull Request n'a pas été fusionnée, la branche cible reste inchangée. Le travail d'Emma existe, visible et discutable dans la Pull Request, mais main continue de pointer vers son état précédent jusqu'à la fusion effective.

Chapitre terminé