Les requêtes d'intégration sont des propositions pour intégrer les modifications de code dans un projet. Une pull request est la principale GitHubfonctionnalité de collaboration de , qui vous permet de discuter des modifications et de les examiner avant de les fusionner. Cela permet aux équipes de travailler ensemble, de détecter les problèmes au début et de maintenir la qualité du code.
Afficher vos pull requestsTraitement des demandes de tirage
Une demande de fusion rassemble le contexte dont les relecteurs ont besoin pour comprendre une modification. Ce contexte est organisé en onglets :
- L’onglet Conversation affiche la description, la chronologie, les commentaires et les révisions.
- L’onglet Commits affiche l’évolution de la branche de la pull request au fil du temps.
- L’onglet Vérifications affiche des tests automatisés, des builds et d’autres validations.
- L’onglet Fichiers modifiés affiche les différences que les réviseurs utilisent pour comprendre les modifications proposées.
- L’onglet Résultats affiche les résultats de révision de code automatisés, tels que les alertes d’analyse du code, pour les modifications proposées.
Séparément des onglets, l’état de fusion met en surbrillance les bloqueurs, les approbations manquantes et d’autres exigences avant la fusion. Il apparaît dans l’en-tête de la pull request et dans l’encadré de fusion.
Ensemble, ces vues aident les auteurs et les réviseurs à discuter de la modification, à suivre les retours et à décider quand la pull request est prête à être fusionnée.
Brouillons de pull requests
Lorsque vous créez une pull request, vous pouvez choisir de la transformer en une demande de tirage en brouillon. Les pull requests en brouillon ne peuvent pas être intégrées et les responsables du code ne sont pas automatiquement sollicités pour les examiner. Les brouillons sont utiles lorsque vous souhaitez partager des travaux en cours sans demander formellement des révisions.
Quand vous êtes prêt à recevoir des commentaires sur votre demande de tirage, vous pouvez marquer votre brouillon de demande de tirage comme étant prêt pour la révision. Le marquage d’une demande de tirage comme étant prête pour la révision demande des révisions à tous les propriétaires de code. Vous pouvez convertir une pull request en brouillon à tout moment. Consultez « Modification de l'étape d'une demande de fusion ».
Références de requête de tirage et branches de fusion
Lorsque vous ouvrez une demande de tirage, GitHub crée des références Git temporaires qui pointent vers la branche principale de la demande de tirage et, dans la mesure du possible, vers un résultat de fusion simulé. Ces références aident GitHub et les intégrations à évaluer la pull request sans modifier la branche de base.
Pour la plupart des contributeurs, ces références restent en arrière-plan. Ils sont particulièrement utiles lorsque vous mettez en place une automatisation, déboguez le comportement de la CI ou récupérez localement l’état des pull requests. Pour plus d’informations sur l’utilisation de la branche de fusion GitHub Actions, consultez Événements qui déclenchent des flux de travail.
Différences entre les commits dans les pages de comparaison et de demande de tirage
Les pages de comparaison et de pull request peuvent calculer les fichiers modifiés depuis différentes bases de fusion. Par conséquent, les mêmes branches peuvent parfois afficher des différences différentes à chaque endroit.
Cela est généralement important lorsque la branche de base a changé depuis que la pull request a été créée. Les pages de demande de tirage se concentrent sur ce que la demande de tirage a introduite, tandis que les pages de comparaison reflètent la comparaison actuelle entre deux références.
Modèles de développement collaboratif
L'utilisation des pull requests dépend du modèle de développement que vous utilisez dans votre projet. Vous pouvez utiliser le système de fork et pull (duplication et tirage) ou le système de référentiel partagé.
Modèle de duplication et de tirage
Dans le modèle de duplication et d’extraction, tout le monde peut dépliquer un référentiel existant (« en amont ») s’il dispose d’un accès en lecture et que le propriétaire du référentiel en amont l’autorise. Sachez qu’un fork et son dépôt en amont partagent les mêmes données Git. Cela signifie que tout le contenu chargé sur une duplication est accessible depuis l’amont et toutes les autres duplications de cet amont.
Vous n’avez pas besoin d’une autorisation du référentiel en amont pour envoyer (push) vers un fork que vous avez créé. Vous pouvez, si vous le souhaitez, autoriser toute personne ayant un accès d'envoi au référentiel source à apporter des modifications à votre branche de demande de tirage. Ce modèle est populaire avec les projets open source, car il réduit les frictions pour les nouveaux contributeurs et permet aux personnes de travailler indépendamment sans coordination initiale.
Conseil
Pour plus d’informations sur l’open source, plus précisément sur la création et la croissance d’un projet open source, nous avons créé des guides sur l’open source qui vous aideront à favoriser une communauté open source saine.Vous pouvez également suivre un cours gratuit GitHub Skills sur la maintenance des communautés open source.
Modèle de référentiel partagé
Dans le modèle de référentiel partagé, les collaborateurs ont un accès push à un référentiel partagé unique et créent des branches de rubrique lorsqu’ils doivent apporter des modifications. Les demandes de tirage sont utiles dans ce modèle, car elles démarrent la révision du code et une discussion générale sur un ensemble de modifications avant que les modifications ne soient fusionnées dans la branche de développement principale. Ce modèle est plus courant avec les petites équipes et les organisations qui collaborent sur des projets privés.