{"meta":{"title":"Fusion des pull requests","intro":"Découvrez les stratégies de fusion des pull requests, notamment les commits de fusion, les fusions par squash et les rebasages, afin de gérer efficacement l’historique du dépôt.","product":"Demandes de tirage","breadcrumbs":[{"href":"/fr/pull-requests","title":"Demandes de tirage"},{"href":"/fr/pull-requests/reference","title":"Référence"},{"href":"/fr/pull-requests/reference/pull-request-merges","title":"Fusion des pull requests"}],"documentType":"article"},"body":"# Fusion des pull requests\n\nDécouvrez les stratégies de fusion des pull requests, notamment les commits de fusion, les fusions par squash et les rebasages, afin de gérer efficacement l’historique du dépôt.\n\nLes 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.\n\n| Strategy             | Résultat                                                                                         | Choisir quand                                                                                                                         |\n| -------------------- | ------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------- |\n| 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.                    |\n| Écraser et fusionner | 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. |\n| 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.                                           |\n\n## Fusionner vos validations\n\nQuand 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`](https://git-scm.com/docs/git-merge#_fast_forward_merge).\n\nPour fusionner les demandes de tirage, vous devez avoir des [autorisations d’écriture](/fr/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/repository-roles-for-an-organization) sur le dépôt.\n\n![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 ».](/assets/images/help/pull_requests/standard-merge-commit-diagram.png)\n\nUn 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.\n\nChoisissez 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.\n\n## Effectuer un squash et une fusion de vos validations\n\nLorsque 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](https://git-scm.com/docs/git-merge#_fast_forward_merge).\n\nPour écraser et fusionner des demandes de tirage, vous devez avoir des [autorisations en écriture](/fr/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/repository-roles-for-an-organization) dans le dépôt, et le dépôt doit [autoriser la fusion par écrasement](/fr/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/configuring-commit-squashing-for-pull-requests).\n\n![Diagramme du squashing de commits, où plusieurs commits d’une branche de fonctionnalité sont combinés en un seul commit ajouté à « main ».](/assets/images/help/pull_requests/commit-squashing-diagram.png)\n\nVous 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.\n\nLa 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.\n\nChoisissez 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.\n\n### Message de fusion pour une fusion de Squash\n\nLorsque 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.\n\nLes 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](/fr/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/configuring-commit-squashing-for-pull-requests) ».\n\n### Squashing et fusion d’une branche longue\n\nLa 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.\n\nPour 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.\n\n## Rebaser et fusionner vos commits\n\nLorsque 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](https://git-scm.com/docs/git-merge#_fast_forward_merge) 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.\n\nLe 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 :\n\n* Met toujours à jour les informations du committer et crée de nouveaux SHA de commit, tandis que `git rebase` ne modifie pas les informations du committer lors du rebasage sur un commit ancêtre.\n* Supprime les validations qui ont été vides pour commencer, telles que celles créées avec `git commit --allow-empty`, tandis que `git rebase` conserve les validations initialement vides par défaut.\n\nPour plus d’informations sur `git rebase`, consultez « [Rebasage Git](https://git-scm.com/docs/git-rebase) » dans la documentation Git.\n\nPour rebaser et fusionner des pull requests, vous devez avoir les [autorisations en écriture](/fr/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/repository-roles-for-an-organization) dans le référentiel, et le référentiel doit [autoriser le rebasage et la fusion](/fr/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/configuring-commit-rebasing-for-pull-requests).\n\nPour obtenir une représentation visuelle de `git rebase`, consultez le chapitre [« Création de branche Git – Rebasage » du manuel *Pro Git*](https://git-scm.com/book/en/v2/Git-Branching-Rebasing).\n\nLe 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.\n\nChoisissez 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](/fr/pull-requests/how-tos/merge-and-close-pull-requests/resolving-a-merge-conflict-using-the-command-line) et [Fusion d'une pull request](/fr/pull-requests/how-tos/merge-and-close-pull-requests/merging-a-pull-request).\n\n## Fusions indirectes\n\nUne 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.\n\nLes 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.\n\n## Lectures complémentaires\n\n* [Requêtes de tirage](/fr/pull-requests/reference/pull-requests)\n* [Fusionner et fermer des pull requests](/fr/pull-requests/how-tos/merge-and-close-pull-requests)"}