À propos des méthodes de fusion sur GitHub

Vous pouvez autoriser les contributeurs disposant d’un accès de transmission de type push à votre dépôt pour fusionner leurs demandes de tirage (pull requests) avec différentes options de fusion ou appliquer une méthode de fusion spécifique pour toutes les demandes de tirage (pull requests) de votre dépôt.

Dans cet article

Vous pouvez configurer les options de fusion de demande de tirage (pull request) pour répondre aux besoins de votre workflow et à vos préférences de gestion de l’historique Git. Pour plus d’informations, consultez « Configuration des fusions de demande de tirage ». Vous pouvez appliquer un type de méthode de fusion, tel que le squashing de commit ou le rebasing, en activant uniquement la méthode souhaitée pour votre dépôt.

Note

Lorsque vous utilisez la file d’attente de fusion, vous ne pouvez plus choisir la méthode de fusion, car elle est contrôlée par la file d’attente. Pour plus d’informations sur les files d’attente de fusion, consultez « Gestion d’une file d’attente de fusion ».

Les méthodes de fusion définies sur le référentiel qui entrent en conflit avec la règle de méthode de fusion empêcheront la fusion. Par exemple, si vous n’autorisez pas la fusion par rebase pour le référentiel, et que la règle de fusion n’autorise la fusion par rebase que sur une branche, cette fusion ne sera pas possible. Pour plus d’informations, consultez « Règles disponibles pour les ensembles de règles ».

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 ».

La méthode de fusion par défaut crée un commit de fusion. Vous pouvez empêcher toute personne de pousser des commits de fusion vers une branche protégée en appliquant un historique de commit linéaire. Pour plus d’informations, consultez « À propos des branches protégées ».

Squashing de vos commits de fusion

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.

Avant d’activer le squashing de commit, tenez compte de ces inconvénients :

  • Vous perdez les informations sur le moment où des modifications spécifiques ont été initialement apportées, et sur qui a créé les commits squashés.
  • Si vous continuez à travailler sur la branche principale d’une demande de tirage (pull request) après le squashing et la fusion, et que vous créez ensuite une nouvelle demande de tirage entre les mêmes branches, les commits que vous avez squashés et fusionnés seront listés dans la nouvelle demande de tirage. Vous pouvez également avoir des conflits que vous devrez résoudre à plusieurs reprises dans chaque demande de tirage successive. Pour plus d’informations, consultez « À propos des fusions de demande de tirage ».
  • Certaines commandes Git qui utilisent l’ID « SHA » ou « hash » peuvent être plus difficiles à utiliser, car l’ID SHA pour les commits d’origine est perdu. Par exemple, l’utilisation de git rerere peut ne pas être aussi efficace.

Pour plus d’informations, consultez « Configuration de la fusion Squash des validations pour les demandes de tirage ».

Rebasing et fusion de vos commits

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 Cloud 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.

Avant d’activer la rebasing de commit, tenez compte des inconvénients suivants :

  • Les contributeurs de dépôts devront peut-être rebaser sur la ligne de commande, résoudre les conflits et forcer la poussée de leurs modifications vers la branche de rubrique de la demande de tirage (ou la branche principale distante) avant de pouvoir utiliser l’option Rebaser et fusionner sur GitHub. La poussée forcée doit être effectuée avec soin, afin que les contributeurs ne remplacent pas le travail sur lequel d’autres personnes ont basé leur travail. Pour en savoir plus sur le moment où l’option Rebaser et fusionner est désactivée sur GitHub et le workflow pour le réactiver, consultez « À propos des fusions de demande de tirage ».

  • Lorsque vous utilisez l’option Rebaser et fusionner sur une demande de tirage, il est important de noter que les validations de la branche principale sont ajoutées à la branche de base sans vérification de la signature de validation. Lorsque vous utilisez cette option, GitHub créent une validation modifiée à l’aide des données et du contenu de la validation d’origine. Cela signifie que GitHub n’a pas vraiment créé cette validation et ne peut donc pas la signer en tant qu’utilisateur de système générique. GitHub n’a pas accès aux clés de signature privées du validateur. Il ne peut donc pas signer la validation au nom de l’utilisateur.

    Une solution de contournement consiste à rebaser et fusionner localement, puis à envoyer les modifications à la branche de base de la demande de tirage.

Pour plus d’informations, consultez « Configuration du rebasage de validation pour les demandes de tirage ».