# 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

끌어오기 요청에 대한 기본 **끌어오기 요청 병합** 옵션을 클릭하면 기능 분기의 모든 커밋이 병합 커밋의 베이스 분기에 추가됩니다. 끌어오기 요청은 [`--no-ff` 옵션을 사용하여 병합됩니다](https://git-scm.com/docs/git-merge#_fast_forward_merge).

끌어오기 요청을 병합하려면 리포지토리에 [쓰기 권한](/ko/enterprise-server@3.20/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/repository-roles-for-an-organization)이 있어야 합니다.

![기능 분기의 커밋과 추가 병합 커밋이 모두 '기본'에 추가되는 표준 병합 및 커밋 흐름의 다이어그램입니다.](/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

끌어오기 요청에 대해 **스쿼시 및 병합** 옵션을 선택하면 끌어오기 요청의 커밋이 단일 커밋으로 스쿼시됩니다. 토픽 분기의 기여자 개별 커밋을 모두 보는 대신 커밋이 하나의 커밋으로 결합되어 기본 분기에 병합됩니다. Squah된 커밋이 있는 끌어오기 요청은 [빨리 감기 옵션](https://git-scm.com/docs/git-merge#_fast_forward_merge)을 사용하여 병합됩니다.

끌어오기 요청을 Squah하고 병합하려면 리포지토리에서 [쓰기 권한](/ko/enterprise-server@3.20/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/repository-roles-for-an-organization)이 있어야 하며 리포지토리에서 [Squah 병합을 허용](/ko/enterprise-server@3.20/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/configuring-commit-squashing-for-pull-requests)해야 합니다.

![기능 분기의 여러 커밋이 '기본'에 추가된 하나의 커밋으로 결합되는 커밋 스쿼싱 다이어그램입니다.](/assets/images/help/pull_requests/commit-squashing-diagram.png)

Squash 및 병합을 사용하여 리포지토리에서 보다 간소화된 Git 기록을 만들 수 있습니다. 진행 중인 작업 커밋은 기능 분기에서 작업할 때 유용하지만 Git 기록을 보존하는 것이 반드시 필요하지는 않습니다. 기본 분기로 병합할 때 이러한 커밋을 하나의 커밋으로 스쿼시하면 변경 내용이 통합되어 명확한 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 [끌어오기 요청에 대한 커밋 Squash 구성](/ko/enterprise-server@3.20/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

끌어오기 요청에 대한 **다시 지정 및 통합** 옵션을 선택하면 병합 커밋 없이 토픽 분기(또는 헤드 분기)의 모든 커밋이 베이스 분기에 개별적으로 추가됩니다. 이러한 방식으로 리베이스 및 병합 동작은 선형 프로젝트 히스토리를 유지하므로 [패스트포워드 병합](https://git-scm.com/docs/git-merge#_fast_forward_merge)과 유사합니다. 그러나 리베이스는 새 커밋으로 기준 브랜치의 커밋 기록을 다시 작성하여 이를 수행합니다.

GitHub 외부에서는 GitHub에서의 리베이스 및 병합 동작이 `git rebase`와 약간 다릅니다.
GitHub에서 리베이스 및 병합:

* 항상 커밋자 정보를 업데이트하고 새 커밋 SHA를 만드는 반면 `git rebase` , 상위 커밋 위에 다시 기반이 발생할 때 커밋 정보를 변경하지는 않습니다.
* 처음에는 비어 있던 커밋(예: 만든 `git commit --allow-empty`커밋)을 삭제하는 반면 `git rebase` , 기본적으로 원래 비어 있는 커밋은 유지됩니다.

`git rebase`에 대한 자세한 내용은 Git 설명서에서 [git-rebase](https://git-scm.com/docs/git-rebase)를 참조하세요.

끌어오기 요청을 다시 지정하고 병합하려면 리포지토리에서 [쓰기 권한](/ko/enterprise-server@3.20/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/repository-roles-for-an-organization)이 있어야 하며 리포지토리에서 [다시 지정 병합을 허용](/ko/enterprise-server@3.20/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/configuring-commit-rebasing-for-pull-requests)해야 합니다.

`git rebase`의 시각적 표현은 [*Pro Git* 책의 "Git Branching - 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](/ko/enterprise-server@3.20/pull-requests/how-tos/merge-and-close-pull-requests/resolving-a-merge-conflict-using-the-command-line) and [Merging a pull request](/ko/enterprise-server@3.20/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](/ko/enterprise-server@3.20/pull-requests/reference/pull-requests)
* [Merge and close pull requests](/ko/enterprise-server@3.20/pull-requests/how-tos/merge-and-close-pull-requests)