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
When you click the default Merge pull request option on a pull request, all commits from the feature branch are added to the base branch in a merge commit. The pull request is merged using the --no-ff option.
To merge pull requests, you must have write permissions in the repository.
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
When you select the Squash and merge option on a pull request, the pull request's commits are squashed into a single commit. Instead of seeing all of a contributor's individual commits from a topic branch, the commits are combined into one commit and merged into the default branch. Pull requests with squashed commits are merged using the fast-forward option.
To squash and merge pull requests, you must have write permissions in the repository, and the repository must allow squash merging.
You can use squash and merge to create a more streamlined Git history in your repository. Work-in-progress commits are helpful when working on a feature branch, but they aren’t necessarily important to retain in the Git history. If you squash these commits into one commit when merging to the default branch, the changes are consolidated, leading to a clear Git history.
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.