Les pull requests peuvent être fusionnées de différentes manières. La meilleure stratégie dépend de la façon dont votre équipe souhaite que l’historique des référentiels soit affiché et de la quantité de détails que vous souhaitez conserver à partir de la branche de demande de tirage.
| Strategy | Résultat | Choisir quand |
|---|---|---|
| Commit de fusion | Préserve chaque commit de la branche de la pull request et ajoute un commit de fusion explicite. | Votre équipe accorde de l’importance à un historique complet, ou les commits individuels ont du sens en eux-mêmes. |
| Squash et intégrer | Combine tous les commits de la pull request en un seul commit sur la branche de destination. | Une pull request représente un seul changement logique, en particulier lorsqu’elle comprend de nombreux petits commits de correction. |
| Rebaser et fusionner | Ajoute chaque commit sur la branche de base sans commit de fusion, pour un historique linéaire. | Votre équipe souhaite un historique linéaire et les commits sont déjà clairement organisés. |
Fusionner vos validations
Quand vous cliquez sur l’option par défaut Fusionner la demande de tirage (pull request) sur une demande de tirage (pull request), tous les commits de la branche de fonctionnalité sont ajoutés à la branche de base dans un commit de fusion. La demande de tirage est fusionnée en utilisant l’option --no-ff.
Pour fusionner les demandes de tirage, vous devez avoir des autorisations d’écriture sur le dépôt.
Un commit de fusion conserve l’historique complet des commits de la branche de la pull request. Cela facilite la consultation de chaque commit ayant conduit à la modification finale, y compris les corrections issues de la revue et le travail intermédiaire. Il crée également un point de fusion explicite dans l’historique des branches de base.
Choisissez cette stratégie si votre équipe accorde de l’importance à l’historique complet ou si les commits individuels d’une pull request ont du sens à eux seuls.
Effectuer un squash et une fusion de vos commits
Lorsque vous sélectionnez l’option Effectuer un squash et une fusion sur une demande de tirage (pull request), les commits de la demande de tirage (pull request) sont écrasés dans un seul commit. Au lieu de voir tous les commits individuels d’un contributeur à partir d’une branche de rubrique, les commits sont regroupés dans un seul commit et fusionnés dans la branche par défaut. Les demandes de tirage avec des commits écrasés sont fusionnées à l’aide de l’option de transfert rapide.
Pour écraser et fusionner des demandes de tirage, vous devez avoir des autorisations en écriture dans le dépôt, et le dépôt doit autoriser la fusion par écrasement.
Vous pouvez utiliser l’option Écraser et fusionner pour créer un historique Git plus épuré dans votre dépôt. Les commits en cours sont utiles quand vous utilisez une branche de fonctionnalités, mais ils ne sont pas nécessairement importants à garder dans l’historique Git. Si vous effectuez un squash de ces commits en un seul commit lors de la fusion avec la branche par défaut, les modifications sont consolidées, ce qui permet d’obtenir un historique Git clair.
La fusion regroupe tous les commits de la pull request en un seul commit sur la branche de base. Cela permet de conserver l’historique des branches par défaut concis et peut faciliter l’analyse ultérieurement. Le compromis est que les commits intermédiaires de la pull request ne sont pas conservés comme des commits distincts dans la branche de base.
Choisissez cette stratégie lorsqu’une pull request représente un seul changement logique, en particulier si la branche comprend de nombreux petits commits de correction.
Message de fusion pour une fusion de Squash
Lorsque vous compressez et fusionnez, GitHub génère un message de commit par défaut que vous pouvez modifier. Le message par défaut peut inclure le titre de la demande de tirage, la description de la demande de tirage ou les informations de validation, en fonction des paramètres du référentiel et du nombre de validations dans la demande de tirage.
Les mainteneurs et les administrateurs peuvent configurer le message par défaut pour les commits écrasés. Consultez « Configuration de la fusion Squash des validations pour les demandes de tirage ».
Fusion et compression d’une branche active depuis longtemps
La fusion squash est plus adaptée aux branches à courte durée de vie. Si vous continuez à travailler sur la même branche source après une fusion squash, les pull requests ultérieures peuvent inclure des commits qui ont déjà été regroupés dans la branche de base. Cela peut rendre les conflits de fusion plus probables et vous forcer à résoudre les mêmes conflits plusieurs fois.
Pour les branches de longue durée, envisagez d’utiliser un commit de fusion ou d’effectuer un rebasage de la branche avant d’ouvrir la pull request suivante.
Rebaser et fusionner vos commits
Lorsque vous sélectionnez l’option Rebaser et fusionner sur une pull request, tous les commits de la branche thématique (ou branche source) sont ajoutés un par un à la branche de base, sans commit de fusion. Ainsi, le comportement de rebasage et de fusion ressemble à une fusion rapide en conservant un historique de projet linéaire. Toutefois, le rebasage permet de réécrire l’historique des validations (commits) sur la branche de base avec de nouvelles validations.
Le comportement de rebase et de fusion sur GitHub diffère légèrement de celui de git rebase en dehors de GitHub. Rebasage et fusion sur GitHub :
- Met toujours à jour les informations du committer et crée de nouveaux SHA de commit, tandis que
git rebasene modifie pas les informations du committer lors du rebasage sur un commit ancêtre. - Supprime les validations qui ont été vides pour commencer, telles que celles créées avec
git commit --allow-empty, tandis quegit rebaseconserve les validations initialement vides par défaut.
Pour plus d’informations sur git rebase, consultez « Rebasage Git » dans la documentation Git.
Pour rebaser et fusionner des pull requests, vous devez avoir les autorisations en écriture dans le référentiel, et le référentiel doit autoriser le rebasage et la fusion.
Pour obtenir une représentation visuelle de git rebase, consultez le chapitre « Création de branche Git – Rebasage » du manuel Pro Git.
Le rebasage applique chaque commit de la branche de la pull request sur la branche de base sans créer de commit de fusion. Cela produit un historique linéaire tout en préservant les commits individuels de la pull request.
Choisissez cette stratégie lorsque votre équipe souhaite un historique linéaire et que les commits de la pull request sont déjà clairement organisés. Si GitHub ne peut pas effectuer le rebase de la pull request automatiquement et en toute sécurité, vous pouvez le faire localement, résoudre les conflits et pousser la branche mise à jour. Consultez Resolving a merge conflict using the command line et Merging a pull request.
Fusions indirectes
Une pull request peut être marquée comme fusionnée si les commits de sa branche source deviennent atteignables depuis la branche de base indépendamment de cette pull request. Cela peut se produire lorsque les mêmes commits sont fusionnés via une autre pull request ou poussés directement vers la branche par défaut.
Les fusions indirectes sont rares, mais elles peuvent affecter les attentes en matière d’automatisation et de protection des branches. Les pull requests fusionnées indirectement sont marquées comme merged même si les règles de protection de branche applicables à cette pull request n’ont pas été respectées.