# 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

pull request で既定の **\[pull request のマージ]** オプションをクリックすると、機能ブランチからのすべてのコミットがマージ コミット内のベース ブランチに追加されます。 pull request は、[`--no-ff` オプション](https://git-scm.com/docs/git-merge#_fast_forward_merge)を使用してマージされます。

pull request をマージするには、リポジトリの[書き込みアクセス許可](/ja/enterprise-server@3.18/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/repository-roles-for-an-organization)が必要です。

![標準的なマージとコミットのフローの図。機能ブランチからのコミットと追加のマージ コミットの両方が "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

pull request で **\[スカッシュとマージ]** オプションを選ぶと、その pull request のコミットが 1 つのコミットにスカッシュされます。 トピックブランチからコントリビュータの個々のコミットをすべて見る代わりに、コミットは１つのコミットにまとめられ、デフォルトブランチにマージされます。 スカッシュされたコミットを含む pull request は、[早送りオプション](https://git-scm.com/docs/git-merge#_fast_forward_merge)を使用してマージされます。

pull request をスカッシュしてマージするには、リポジトリに[書き込みアクセス許可](/ja/enterprise-server@3.18/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/repository-roles-for-an-organization)が必要であり、リポジトリで[スカッシュ マージが許可](/ja/enterprise-server@3.18/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/configuring-commit-squashing-for-pull-requests)されている必要があります。

![コミットのスカッシュの図。機能ブランチからの複数のコミットが、main に追加されるただ 1 つのコミットに結合されています。](/assets/images/help/pull_requests/commit-squashing-diagram.png)

squashとマージは、よりスムーズなGitの履歴をリポジトリに作り出すために利用できます。 作業途中でのコミットは、フィーチャブランチで作業しているときには役立ちますが、必ずしもGitの履歴に残すほど重要とはかぎりません。 既定のブランチにマージするときにこれらのコミットを 1 つのコミットに squash すると、変更が統合され、Git の履歴がわかりやすくなります。

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 [プルリクエストにコミットの圧縮を設定する](/ja/enterprise-server@3.18/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

pull request で **\[リベースとマージ]** オプションを選択すると、トピック ブランチ (または head ブランチ) からのすべてのコミットが、マージ コミットなしに個別にベース ブランチに追加されます。 このように、リベースとマージの動作は、線形プロジェクト履歴を維持することで、[早送りマージ](https://git-scm.com/docs/git-merge#_fast_forward_merge) に似ています。 しかし、リベースは、ベース ブランチのコミット履歴を新しいコミットで書き直すことでこれを実現します。

GitHub でのリベースとマージの動作は、`git rebase` とは少し異なっています。 GitHub でリベースしてマージすると、常にコミッター情報が更新され、新しいコミット SHA が作成されますが、GitHub 外の `git rebase` は、先祖コミットの上でリベースが発生した場合、コミッター情報は変更されません。 `git rebase` の詳細については、Git ドキュメントの「[git-rebase](https://git-scm.com/docs/git-rebase)」を参照してください。

pull request をリベースしてマージするには、リポジトリに[書き込みアクセス許可](/ja/enterprise-server@3.18/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/repository-roles-for-an-organization)が必要であり、リポジトリで[リベース マージが許可](/ja/enterprise-server@3.18/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/configuring-commit-rebasing-for-pull-requests)されている必要があります。

`git rebase` の視覚的表現については、[*ProGit* ブックの「GitBranching-Rebasing」の章](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](/ja/enterprise-server@3.18/pull-requests/how-tos/merge-and-close-pull-requests/resolving-a-merge-conflict-using-the-command-line) and [Merging a pull request](/ja/enterprise-server@3.18/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](/ja/enterprise-server@3.18/pull-requests/reference/pull-requests)
* [Merge and close pull requests](/ja/enterprise-server@3.18/pull-requests/how-tos/merge-and-close-pull-requests)