À propos des fusions de demande de tirage

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.

Diagramme d’un flux de fusion et de commit standard, où les commits d’une branche de fonctionnalité et un commit de fusion supplémentaire sont tous deux ajoutés à « main ».

Effectuer un squash et une fusion de vos validations

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.

Diagramme du squashing de commits, où plusieurs commits d’une branche de fonctionnalité sont combinés en un seul commit ajouté à « main ».

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 écrasez ces commits dans un seul commit lors de la fusion dans la branche par défaut, vous pouvez garder les modifications d’origine avec un historique Git clair.

Message de fusion pour une fusion de Squash

Lorsque vous effectuez un squash et une fusion, GitHub génère un message de validation par défaut que vous pouvez modifier. Selon la façon dont le référentiel est configuré et le nombre de validations dans la demande de tirage, sans inclure les validations de fusion, ce message peut inclure le titre de la demande de tirage, la description de la demande de tirage ou des informations sur les validations.

Nombre de validations	Résumé	Description
Une validation	Titre du message de validation pour la validation unique, suivi du numéro de la demande de tirage	Texte du corps du message de validation pour la validation unique
Plusieurs validations	Titre de la demande de tirage, suivi du numéro de la demande de tirage	Liste des messages de validation pour toutes les validations ayant fait l’objet d’un squash, par ordre de date

Les personnes avec un accès gestionnaire ou administrateur à un référentiel peuvent configurer le message de fusion par défaut du référentiel pour que toutes les validations écrasées utilisent le titre de la demande de tirage, le titre de la demande de tirage et les détails de validation, ou le titre et la description de la demande de tirage. Pour plus d’informations, consultez « Configuration de la fusion Squash des validations pour les demandes de tirage ».

Squashing et fusion d’une branche longue

Si vous prévoyez de continuer à travailler sur la branche principale d’une demande de tirage une fois cette dernière fusionnée, nous vous recommandons de ne pas soumettre la demande de tirage à un squash ou une fusion.

Lorsque vous créez une demande de tirage, GitHub identifie la validation la plus récente située sur la branche principale et la branche de base : la validation ancêtre commune. Lorsque soumettez la demande de tirage à un squash et une fusion, GitHub crée une validation sur la branche de base qui contient toutes les modifications que vous avez apportées à la branche principale depuis la validation ancêtre commune.

Cette validation se trouvant uniquement sur la branche de base et non sur la branche principale, l’ancêtre commun des deux branches ne change pas. Si vous continuez à travailler sur la branche principale, créez une nouvelle demande de tirage entre les deux branches. La demande de tirage inclura toutes les validations depuis l’ancêtre commun, y compris les validations ayant fait l’objet d’un squash et d’une fusion dans la demande de tirage précédente. En l’absence de conflits, vous pouvez fusionner ces validations en toute sécurité. Cela étant, ce workflow peut créer des conflits. Si vous continuez à soumettre les demandes de tirage d’une branche principale longue à un squash et une fusion, vous devrez résoudre les mêmes conflits à plusieurs reprises.

Rebaser et fusionner vos validations

Quand vous sélectionnez l’option Rebase et fusion sur une demande de tirage (pull request), toutes les validations (commits) de la branche de rubrique (ou branche principale) sont ajoutées individuellement à la branche de base sans validation 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 rebasage et de fusion sur GitHub Enterprise Server s’écarte légèrement de git rebase. Les opérations de rebasage et de fusion sur GitHub mettent toujours à jour les informations du commiter et créent de nouveaux SHA de commit, tandis que git rebase en dehors de GitHub ne modifie pas les informations du commiter quand le rebasage se produit au-dessus d’une validation (commit) ancêtre. Pour plus d’informations sur git rebase, consultez « Rebasage Git » dans la documentation Git.

Pour rebaser et fusionner des demandes de tirage (pull requests), vous devez disposer d’autorisations d’écriture dans le référentiel, et le référentiel doit autoriser la fusion de rebasage.

Pour obtenir une représentation visuelle de git rebase, consultez le chapitre « Création de branche Git – Rebasage » du manuel Pro Git.

Vous ne pouvez pas rebaser et fusionner automatiquement quand :

La demande de tirage présente des conflits de fusion.
La rebasage des validations de la branche de base vers la branche principale entraîne des conflits.
Le rebasage des validations est considéré comme « dangereux », par exemple lorsqu’une rebase est possible sans conflits de fusion, mais produit un résultat différent de celui d’une fusion.

Si vous souhaitez toujours rebaser les validations, mais que vous ne pouvez pas rebaser et fusionner automatiquement, vous devez :

Rebaser la branche de rubrique (ou branche principale) sur la branche de base localement sur la ligne de commande
Résoudre les conflits de fusion sur la ligne de commande.
Forcer l’envoi (push) des validations rebasées vers la branche de rubrique de la demande de tirage (ou la branche principale distante).

Toute personne disposant d’autorisations d’écriture dans le dépôt peut alors fusionner les modifications à l’aide du bouton rebaser et fusionner.

Fusions indirectes

Une demande de tirage peut être fusionnée automatiquement si sa branche principale est directement ou indirectement fusionnée dans la branche de base en externe. En d’autres termes, si la validation de pointe de la branche principale devient accessible à partir de l’extrémité de la branche cible. Par exemple :

La branche main se trouve à la validation C.
La branche feature a été déconnectée de main et se trouve actuellement à la validation D. Cette branche a une demande de tirage ciblant main.
La branche feature_2 est déconnectée de feature et se trouve maintenant à la validation E. Cette branche a également une demande de tirage ciblant main.

Si la demande de tirage E --> main est fusionnée en premier, la demande de tirage D --> main est marquée comme fusionnée automatiquement, car toutes les validations de feature sont désormais accessibles à partir de main. La fusion de feature_2 dans main et l’envoi de main à partir de la ligne de commande marquera les deux demandes de tirage comme fusionnées.

Les fusions indirectes ne peuvent se produire que lorsque les validations dans le branche de tête de la demande de tirage sont envoyés directement à la branche par défaut du référentiel ou lorsque les validations dans le branche de tête de la demande de tirage sont présents dans une autre demande de tirage et sont fusionnés dans la branche par défaut du référentiel à l’aide de l’utilisation de l’option Créer une validation de fusion.

Si une demande de tirage contenant des validations présentes dans la branche de tête d’une autre demande de tirage est fusionnée à l’aide des options Squash et fusionner ou Rebaser et fusionner, une nouvelle validation est créée sur la branche de base et l’autre demande de tirage ne sera pas automatiquement fusionnée.

Les demandes de tirage qui sont fusionnées indirectement sont marquées comme merged, même si les règles de protection de branche n’ont pas été respectées.

Dans cet article