Cursus
Les pull requests ont aidé mes équipes à éviter les bugs, à s'aligner sur les décisions de mise en œuvre et à apprendre les uns des autres grâce à leur code. Dans ce guide, je vais vous montrer comment utiliser les pull requests dans les plateformes basées sur Git pour réviser votre code en toute sécurité.
Si vous débutez avec Git, je vous recommande de suivrenos cours Introduction à Git et Introduction aux concepts GitHub afin de vous familiariser avec le contrôle de version et les différences entre Git et GitHub. De plus, je trouve que le Git Cheat Sheet, que vous pouvez télécharger, est uneréférence utilecar il contient tous les termes et commandes Git les plus courants.
Qu'est-ce qu'une demande d'extraction ?
Une pull request est en réalité une méthode permettant de suggérer des modifications au code. Imaginez que vous travaillez sur une fonctionnalité ou dans une branche distincte. Une pull request vous permet de demander à ce que ces modifications soient fusionnées dans le code principal. Cela est généralement effectué après que d'autres personnes aient eu l'occasion de les examiner. Les pull requests constituent un élément central du développement collaboratif, en particulier lorsque l'on travaille en équipe.
Il est important de noter que sur GitLab, ce processus est appelé « Merge Request » (demande de fusion).
Comment fonctionne une demande d'extraction ?
Les étapes suivantes décrivent le déroulement général d'une pull request :
- Apportez des modifications au script (code) dans une branche de fonctionnalité.
- Enregistrez ces modifications dans votre référentiel local.
- Veuillez pousser la branche vers le référentiel distant tel que GitHub.
- Veuillez ouvrir une demande d'extraction pour suggérer les modifications à apporter à la branche principale.
- Veuillez demander une révision des modifications proposées.
- Fusionnez ou fermez la pull request en fonction du résultat.
Ce flux de travail permet à chaque développeur de réviser le code et d'identifier les problèmes potentiels avant de le mettre en production.
Les rôles clés dans le processus de pull request sont les suivants :
- Contributeur : Le développeur qui apporte des modifications et ouvre la pull request.
- Critique : Il s'agit du développeur qui examine les modifications proposées au code afin de suggérer des améliorations et de garantir la qualité du code.
- Responsable de la maintenance : Le chef de projet qui est responsable du projet et qui est habilité à approuver ou rejeter les demandes d'extraction.
Je vous recommande de suivre notre cours Git intermédiaire pour apprendre àcréer des branches dans Git et à collaborer à distance avec les membres de votre équipe.
Création d'une pull request (avec un exemple)
Supposons que vous remarquiez une erreur dans la ligne d'introduction du fichier README de votre projet. Vous souhaitez résoudre ce problème sans affecter la branche principale. Veuillez suivre les étapes ci-dessous :
Étape 1 : Créer une nouvelle branche
Veuillez vous rendre dans le dossier de votre projet et ouvrir le terminal pour exécuter la commande ci-dessous. Cette ligne crée une autre branche.
git checkout -b fix-readme-typo
Étape 2 : Effectuez votre changement
Pour corriger le fichier, veuillez ouvrir le fichier README.md
dans votre éditeur de code, corriger la faute de frappe, puis enregistrer le fichier.
Étape 3 : Valider les modifications
Validez et enregistrez les modifications à l'aide de la commande ci-dessous :
git add README.md
git commit -m "Fix typo in README"
Étape 4 : Veuillez pousser la branche vers GitHub.
Veuillez télécharger la branche vers le référentiel.
git push origin fix-readme-typo
Étape 5 : Ouvrez GitHub et créez une demande d'extraction.
Veuillez maintenant ouvrir votre compte GitHub et procéder comme suit :
-
Accédez à votre référentiel sur GitHub.
-
Sélectionnez l'invite Comparer et extraire la demande pour votre branche poussée.
-
Ajoutez un titre tel que « Corriger une faute de frappe dans README » et rédigez une brève description si vous le souhaitez.
-
Sélectionnez votre branche de base (généralement
main
) et comparez-la avec votre branche de fonctionnalité.
Étape 6 : Demander une révision et soumettre
Si votre projet implique d'autres développeurs, vous pouvez demander des réviseurs ou ajouter des étiquettes si le projet les utilise. Veuillez ensuite cliquer sur « Create pull request » (Créer une demande d'extraction).
Veuillez consulter notre projet sur la réalisation d'une revue de code pour comprendre comment examiner et apporter des modifications avant de mettre le code en production.
Meilleures pratiques en matière de pull requests
Voici les meilleures pratiques à suivre pour garantir un développement de qualité lors de la création de pull requests :
- Veuillez veiller à ce que vos demandes d'extraction soient concises et simples : Commencez toujours par une seule demande d'extraction pour chaque fonctionnalité que vous souhaitez suggérer. Cela permet au réviseur de suivre et de tester vos modifications et minimise le risque d'introduire un bogue.
- Veuillez rédiger des messages et des descriptions clairs lors de la validation : Veuillez fournir des messages de validation descriptifs afin d'expliquer les modifications apportées. Ce contexte aide les réviseurs à comprendre votre intention sans avoir à examiner le code en détail.
- Tirez parti des demandes d'extraction de brouillons pour obtenir des commentaires rapides : Si votre travail n'est pas terminé mais que vous souhaitez obtenir des commentaires, veuillez créer une demande d'extraction provisoire. Cela indique que votre code est en cours de développement et invite à la discussion sans obligation de fusionner immédiatement.
- Veuillez tester minutieusement et partager le contexte : Veuillez toujours vérifier vos modifications afin de vous assurer que tout fonctionne comme prévu.
Demandes d'extraction dans les workflows Git
Voici un aperçu rapide de la manière dont différentes configurations d'équipe utilisent les pull requests.
-
Branchement de fonctionnalités : Ceci est courant dans les petites équipes et les référentiels privés. Ce flux de travail implique la création d'une nouvelle branche pour chaque fonctionnalité.
-
Forking du flux de travail : Ce flux de travail est utilisé dans les projets open source. Le processus de bifurcation nécessite que les contributeurs effectuent une bifurcation (copie) du référentiel principal vers leur compte. Ils apportent des modifications à leur fourche, puis ouvrent une demande d'extraction vers l'original.
-
GitFlow : Il s'agit d'un flux de travail structuré qui utilise des branches à long terme telles que
main
,develop
,release
ethotfix
. Il est utilisé par les équipes plus importantes ayant des cycles de publication plus complexes.
Étiquette relative aux demandes d'extraction
Il est possible que certaines demandes soient inappropriées, c'est pourquoi les pull requests sont soumises à certaines règles de conduite :
- Soyez respectueux et précis : Concentrez-vous sur le code, pas sur l'individu.
- Veuillez vous assurer que les demandes d'extraction restent pertinentes : Évitez de mélanger des modifications sans rapport entre elles dans une seule pull request. Cela complique la révision et les commentaires.
- Répondez de manière réfléchie aux commentaires : Reconnaissez le code bien écrit et les suggestions d'amélioration.
- Ne laissez pas les demandes d'extraction en attente trop longtemps : Veuillez toujours examiner et résoudre les demandes d'extraction dans les meilleurs délais afin d'éviter tout retard dans les mises à jour.
- Posez des questions : Si quelque chose n'est pas clair, veuillez demander des précisions plutôt que de présumer des intentions, afin d'éviter tout malentendu.
- Suggérer des améliorations : Le cas échéant, veuillez proposer des conseils concrets ou des approches alternatives plutôt que de simplement souligner les problèmes.
Workflows avancés pour les pull requests et meilleures pratiques
Si vous êtes un développeur expérimenté et que vous souhaitez faciliter la collaboration, améliorer la qualité du code et optimiser votre processus de pull request, voici quelques conseils pratiques pour affiner votre workflow.
Des flux de travail plus intelligents
Divers workflows Git gèrent les pull requests de différentes manières. Comme nous l'avons mentionné précédemment, le Feature Branching est idéal pour les petites équipes en raison de sa simplicité. Cependant, cela peut devenir difficile à gérer si votre équipe s'agrandit.
Le fork est recommandé pour les projets open source, mais peut entraîner une surcharge lors de la synchronisation et de la révision des contributions externes. De même, GitFlow est recommandé dans le cadre d'un développement rapide, bien que sa complexité puisse ralentir le processus.
Automatisation et intégration
Les pull requests modernes disposent de contrôles CI/CD qui automatisent les contrôles qualité en intégrant des outils d'intégration continue qui exécutent des tests et des linters et déploient des aperçus sur chaque PR. Cela garantit que seul le code qui répond aux normes définies est fusionné.
Des plateformes telles que GitHub Actions et GitLab Pipelines permettent également l'automatisation. Ces processus comprennent l'exécution de tests unitaires, la création et le déploiement d'environnements de prévisualisation, la réduction des efforts manuels et la détection précoce des problèmes.
Optimisation des avis
Veuillez toujours veiller à ce que les demandes d'extraction soient courtes et précises afin qu'elles puissent être examinées rapidement et de manière approfondie. L'utilisation de modèles comportant des champs clairs tels que « Quels sont les changements » et « Comment tester » aide les contributeurs à fournir des informations concises et pertinentes, ce qui rend les révisions plus efficaces.
Veuillez également noter que poser des questions plutôt que formuler des exigences favorise un dialogue constructif et l'apprentissage. En définissant des délais pour les révisions, vous garantissez la prévisibilité du processus et évitez les retards.
Indicateurs et outils modernes
Je vous recommande également de suivre la taille des PR, le temps nécessaire à leur révision et le taux de fusion afin d'identifier les goulots d'étranglement et d'améliorer l'efficacité du flux de travail. Pour faciliter les révisions et les fusions, veuillez utiliser une demande de modification empilée. Cela permettrait de diviser les fonctionnalités importantes en plusieurs PR plus petites et connectées qui s'appuient les unes sur les autres.
De plus, vous pouvez intégrer des outils d'IA tels que GitHub Copilot ou CodeWhisperer lorsque vous utilisez des pull requests. Ces outils vous aideront à identifier rapidement les problèmes potentiels et vous suggéreront des solutions pour les résoudre.
Demandes d'extraction vs. Demandes de fusion
Dans GitHub et GitLab, les Pull Requests (PR) et les Merge Requests (MR) sont utilisées de manière interchangeable. Bien qu'elles aient le même objectif, chaque plateforme les gère différemment.
Le tableau ci-dessous compare les RP et les MR afin de mettre en évidence ces différences.
Aspect |
Demande d'extraction (GitHub) |
Demande de fusion (GitLab) |
Terminologie |
Demande de suppression des modifications |
Demande de fusion des modifications |
Utilisation principale |
Proposer, examiner et fusionner les modifications apportées au code. |
Proposer, examiner et fusionner les modifications apportées au code. |
Utilisateurs types |
Développeurs open source, petites et moyennes équipes |
Équipes, entreprises et référentiels privés fortement axés sur DevOps |
Intégration CI/CD |
Actions GitHub (facultatif, nécessite une configuration) |
CI/CD intégré par défaut |
Soutien à la rédaction |
Prise en charge native des PR provisoires |
Prise en charge via le libellé « Brouillon » ou les préfixes WIP |
Fusionner les approbations |
Paramètres de base pour les réviseurs et les approbateurs |
Règles avancées : approbateurs multiples, pipelines d'approbation |
Stratégies de fusion |
Fusionner, fusionner ou rebaser une validation |
Options similaires, avec restrictions de méthode de fusion configurables. |
Philosophie du flux de travail |
Axé sur les développeurs, flexible |
Axé sur le DevOps, avec une intégration étroite entre le développement et les opérations. |
Conclusion
Les pull requests sont indispensables pour tout projet sérieux. Comme vous avez pu le constater (et j'espère que vous l'appréciez désormais), ils permettent aux équipes de réviser, discuter et améliorer le code de manière collaborative.
Continuez à améliorer vos compétences en tant que développeur. Consultez nos cursus Git Fundamentals et GitHub Foundations pour devenir un expert en Git.
Apprenez les bases de Git dès aujourd'hui
FAQ sur les demandes d'extraction
Une pull request est-elle identique à une merge request ?
GitHub appelle cela une « pull request », tandis que GitLab utilise le terme « merge request », mais les deux effectuent la même tâche.
Puis-je apporter des modifications à une pull request après l'avoir ouverte ?
Oui, si vous poussez de nouveaux commits vers la même branche, la pull request sera automatiquement mise à jour.
Puis-je supprimer une branche après avoir fusionné une pull request ?
Oui, il est recommandé de supprimer la branche après avoir fusionné la pull request afin de garder votre référentiel bien organisé.
Qu'est-ce qu'une demande d'extraction provisoire ?
Une demande d'extraction provisoire est une demande d'extraction « en cours ». Vous pouvez l'utiliser lorsque vous n'êtes pas encore prêt à fusionner, mais que vous souhaitez obtenir rapidement des commentaires.
Quelle est la différence entre une pull request et une branche ?
Une branche est une ligne de développement distincte, tandis qu'une pull request est une proposition formelle visant à fusionner les modifications de cette branche dans une autre branche.