Skip to main content

À propos des fusions de demande de tirage

Vous pouvez fusionner des demandes de tirage (pull request) en conservant tous les commits dans une branche de fonctionnalité, en effectuant un squash de tous les commits en un seul commit ou en rebasant des commits individuels de la branche head sur la branche base.

Fusionner vos validations

Quand vous cliquez sur l’option par défaut Fusionner la demande de tirage sur une demande de tirage sur your enterprise 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.

standard-merge-commit-diagram

Effectuer un squash et une fusion de vos validations

Lorsque vous sélectionnez l’option Écraser et fusionner sur une demande de tirage dans your enterprise, les commits de la demande de tirage 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.

commit-squashing-diagram

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. Le message par défaut dépend du nombre de validations de la demande de tirage, sans inclure les validations de fusion.

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

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) sur your enterprise, 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 AE 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 sur your enterprise lorsque :

  • 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 sur your enterprise, 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 référentiel peut alors fusionner les modifications à l’aide du bouton rebaser et fusionner sur your enterprise.

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.

Dans ce cas, les demandes de tirage sont marquées comme étant merged même si les règles de protection de branche n’ont pas été respectées.

Pour aller plus loin