# Pull request merges

Learn strategies for merging pull requests, including merge commits, squash merges, and rebases, to manage repository history effectively.

Pull requests can be merged in different ways. The best strategy depends on how your team wants the repository history to look and how much detail you want to preserve from the pull request branch.

| Strategy         | Result                                                                                | Choose when                                                                               |
| ---------------- | ------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- |
| Merge commit     | Preserves every commit from the pull request branch and adds an explicit merge point. | Your team values complete history, or the individual commits are meaningful on their own. |
| Squash and merge | Combines all commits in the pull request into a single commit on the base branch.     | A pull request represents one logical change, especially with many small fixup commits.   |
| Rebase and merge | Adds each commit onto the base branch without a merge commit, for a linear history.   | Your team wants a linear history and the commits are already organized clearly.           |

## Merge your commits

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`](https://git-scm.com/docs/git-merge#_fast_forward_merge).

Pour fusionner les demandes de tirage, vous devez avoir des [autorisations d’écriture](/fr/enterprise-server@3.21/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/repository-roles-for-an-organization) 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 ».](/assets/images/help/pull_requests/standard-merge-commit-diagram.png)

A merge commit preserves the full commit history from the pull request branch. This makes it easier to see every commit that led to the final change, including review fixes and intermediate work. It also creates an explicit merge point in the base branch history.

Choose this strategy when your team values complete history or when the individual commits in a pull request are meaningful on their own.

## Squash and merge your 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](https://git-scm.com/docs/git-merge#_fast_forward_merge).

Pour écraser et fusionner des demandes de tirage, vous devez avoir des [autorisations en écriture](/fr/enterprise-server@3.21/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/enterprise-server@3.21/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/configuring-commit-squashing-for-pull-requests).

![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)

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.

Squashing turns all commits in the pull request into one commit on the base branch. This keeps the default branch history concise and can make it easier to scan later. The tradeoff is that intermediate commits from the pull request are not preserved as separate commits on the base branch.

Choose this strategy when a pull request represents one logical change, especially if the branch includes many small fixup commits.

### Merge message for a squash merge

When you squash and merge, GitHub generates a default commit message that you can edit. The default message can include the pull request title, pull request description, or commit information, depending on repository settings and the number of commits in the pull request.

Maintainers and administrators can configure the default message for squashed commits. See [Configuration de la fusion Squash des validations pour les demandes de tirage](/fr/enterprise-server@3.21/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/configuring-commit-squashing-for-pull-requests).

### Squashing and merging a long-running branch

Squash merging works best for short-lived branches. If you keep working on the same head branch after a squash merge, later pull requests can include commits that were already squashed into the base branch. This can make merge conflicts more likely and can force you to resolve the same conflicts more than once.

For long-running branches, consider using a merge commit or rebasing the branch before opening the next pull request.

## Rebase and merge your 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](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.

Le comportement de rebase et de fusion sur GitHub 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](https://git-scm.com/docs/git-rebase) » dans la documentation Git.

Pour rebaser et fusionner des demandes de tirage (pull requests), vous devez disposer [d’autorisations d’écriture](/fr/enterprise-server@3.21/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 la fusion de rebasage](/fr/enterprise-server@3.21/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/configuring-commit-rebasing-for-pull-requests).

Pour 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).

Rebasing adds each commit from the pull request branch onto the base branch without creating a merge commit. This produces a linear history while preserving the individual commits from the pull request.

Choose this strategy when your team wants a linear history and the pull request commits are already organized clearly. If GitHub cannot safely rebase the pull request automatically, you can rebase locally, resolve conflicts, and push the updated branch. See [Resolving a merge conflict using the command line](/fr/enterprise-server@3.21/pull-requests/how-tos/merge-and-close-pull-requests/resolving-a-merge-conflict-using-the-command-line) and [Merging a pull request](/fr/enterprise-server@3.21/pull-requests/how-tos/merge-and-close-pull-requests/merging-a-pull-request).

## Indirect merges

A pull request can be marked as merged if its head branch commits become reachable from the base branch outside that pull request. This can happen when the same commits are merged through another pull request or pushed directly to the default branch.

Indirect merges are uncommon, but they can affect automation and branch protection expectations. Pull requests merged indirectly are marked as `merged` even if branch protection rules on that pull request were not satisfied.

## Further reading

* [Pull requests](/fr/enterprise-server@3.21/pull-requests/reference/pull-requests)
* [Merge and close pull requests](/fr/enterprise-server@3.21/pull-requests/how-tos/merge-and-close-pull-requests)