La dernière étape d’une pull request consiste à intégrer le travail terminé dans la branche de déploiement. Cela signifie généralement la fusion de vos modifications dans la version ou la branche principale. Avant cela, vous devez confirmer que la modification répond aux exigences du projet.
Validation des vérifications de prédéploiement
Avant de fusionner, vous allez confirmer que la modification est sûre à déployer. Les vérifications d’état indiquent si les validations répondent aux conditions définies pour le référentiel, telles que les builds d’intégration continue, les tests, l’analyse du code ou les vérifications de déploiement. Ils vous aident, vous et les relecteurs, à comprendre si une pull request est prête à être fusionnée.
Les dépôts exigent souvent que certaines conditions soient remplies avant qu’une pull request puisse être fusionnée, notamment :
- Vérifications d’état requises qui doivent passer, telles que les vérifications d’intégrité et de préparation des applications exécutées par votre pipeline de déploiement.
- Révisions requises ou approbations du propriétaire du code.
- Les conflits de fusion doivent être résolus.
Les branches protégées appliquent ces exigences afin que les branches de déploiement restent stables.
Toutes les vérifications ne sont pas les mêmes. Les vérifications enrichies créées par des produits comme GitHub Actions peuvent signaler des journaux détaillés et des annotations, tandis que les états de validation plus simples peuvent être publiés par divers systèmes connectés. Comprendre ces éléments vous aide à interpréter pourquoi une pull request est prête ou non.
Fusion du code dans la version ou la branche principale
Une fois les conditions requises remplies, vous fusionnez la pull request pour intégrer ses commits dans la branche de base. Vous pouvez également automatiser la fusion de sorte qu’une pull request soit fusionnée dès que les conditions requises sont remplies. Les demandes de tirage proposent différentes stratégies de fusion en fonction de la façon dont vous souhaitez que l’historique du référentiel se présente :
- Le commit de fusion préserve chaque commit de la branche de pull request et ajoute un point de fusion explicite.
- Squash and merge combine tous les commits en un seul commit, pour obtenir un historique plus concis.
- Rebaser et fusionner applique chaque commit sur la branche de base pour obtenir un historique linéaire sans commit de fusion.
La meilleure stratégie dépend de la quantité de détails que votre équipe souhaite conserver.
Application des exigences à grande échelle
Lorsque la fusion est plus rapide, les équipes ajoutent des contrôles pour assurer la sécurité et la prédictible des fusions :
- Les ensembles de règles et les protections de branche peuvent nécessiter une branche up-to-date, des validations signées, un historique linéaire ou des vérifications d’état spécifiques avant la fusion.
- Une file d’attente de fusion permet à une branche protégée très sollicitée d’accepter de nombreuses pull requests sans la casser. Il teste chacun d’eux par rapport à la dernière version de la branche de base et les fusionne dans l’ordre une fois les vérifications passées. Lorsqu’une branche utilise une file d’attente de fusion, les options de fusion disponibles diffèrent d’une fusion standard.
Remarque
Les files d’attente de fusion de demandes de tirage (pull requests) sont disponibles dans n’importe quel dépôt public appartenant à une organisation ou dans les dépôts privés appartenant aux organisations utilisant GitHub Enterprise Cloud. Consultez « plans de GitHub ».
Connexion de fusions au déploiement
La fusion est souvent l’élément déclencheur qui met le code en production. GitHub Actions peut exécuter des workflows de déploiement lorsqu’une pull request est fusionnée dans une branche release ou main. Les environnements de déploiement ajoutent une autre couche de sécurité de prédéploiement : vous pouvez exiger des réviseurs, des minuteurs d’attente ou des restrictions de branche spécifiques avant qu’un déploiement ne se poursuive, et ceux-ci sont exposés en même temps que vos autres vérifications.
Récupération après une fusion
Même avec des vérifications en place, certaines fusions doivent être annulées. Vous pouvez annuler une pull request fusionnée pour créer une nouvelle pull request qui annule ces modifications. Sachez qu’une pull request peut être marquée comme fusionnée indirectement dans de rares cas, si ses commits atteignent la branche de destination par un autre biais. Cela peut contourner les protections pour cette pull request spécifique. Consultez Réinitialisation d’une pull request et Fusion des pull requests.
Fermeture des pull requests qui ne seront pas fusionnées
Toutes les demandes de fusion n’ont pas vocation à être fusionnées. Si une modification n’est plus nécessaire ou est rendue obsolète par d’autres travaux, vous pouvez fermer la pull request sans la fusionner. La fermeture maintient la discussion et l’historique pour référence tout en signalant que le changement ne progressera pas.
Une fois qu’une pull request est fusionnée ou fermée, sa branche source n’est souvent plus nécessaire. La suppression de branches inutilisées permet de faciliter la navigation du référentiel.