# 끌어오기 요청 병합

리포지토리 기록을 효과적으로 관리하기 위해 병합 커밋, 스쿼시 병합 및 다시베이스를 비롯한 끌어오기 요청을 병합하기 위한 전략을 알아봅니다.

끌어오기 요청은 여러 가지 방법으로 병합할 수 있습니다. 최상의 전략은 팀이 리포지토리 기록을 찾는 방법과 끌어오기 요청 분기에서 유지할 세부 정보 양에 따라 달라집니다.

| Strategy   | Result                                            | 시기 선택                                                    |
| ---------- | ------------------------------------------------- | -------------------------------------------------------- |
| 병합 커밋      | 끌어오기 요청 분기의 모든 커밋을 유지하고 명시적 병합 지점을 추가합니다.         | 팀에서 전체 이력을 중요하게 여기거나, 개별 커밋 하나하나가 그 자체로 의미가 있습니다.        |
| 스쿼시 및 병합   | 끌어오기 요청의 모든 커밋을 기본 분기의 단일 커밋으로 결합합니다.             | 풀 리퀘스트는 하나의 논리적 변경을 나타내며, 특히 자잘한 수정 커밋이 많은 경우에 더욱 그렇습니다. |
| 다시 기반 및 병합 | 선형 기록을 유지하기 위해 병합 커밋 없이 각 커밋을 베이스 브랜치에 차례로 적용합니다. | 팀은 선형 기록을 원하고 커밋은 이미 명확하게 구성되어 있습니다.                     |

## 커밋을 병합하세요

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

끌어오기 요청을 병합하려면 리포지토리에 [쓰기 권한](/ko/enterprise-server@3.18/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)

병합 커밋은 끌어오기 요청 분기의 전체 커밋 기록을 유지합니다. 이렇게 하면 검토 수정 및 중간 작업을 포함하여 최종 변경으로 이어진 모든 커밋을 더 쉽게 볼 수 있습니다. 또한 기본 분기 기록에 명시적 병합 지점을 만듭니다.

팀이 전체 기록을 중요하게 여기거나 풀 리퀘스트의 개별 커밋 자체로 의미가 있는 경우 이 전략을 선택합니다.

## 커밋을 스쿼시한 후 병합

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

끌어오기 요청을 Squah하고 병합하려면 리포지토리에서 [쓰기 권한](/ko/enterprise-server@3.18/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/repository-roles-for-an-organization)이 있어야 하며 리포지토리에서 [Squah 병합을 허용](/ko/enterprise-server@3.18/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 기록이 됩니다.

스쿼시는 끌어오기 요청의 모든 커밋을 기본 분기의 하나의 커밋으로 바꿉니다. 이렇게 하면 기본 분기 기록이 간결하게 유지되며 나중에 더 쉽게 검색할 수 있습니다. 대신 풀 리퀘스트의 중간 커밋은 기반 브랜치에 개별 커밋으로 보존되지 않습니다.

끌어오기 요청이 하나의 논리적 변경 내용을 나타내는 경우, 특히 분기에 작은 수정 커밋이 많은 경우 이 전략을 선택합니다.

### Squash 병합에 대한 병합 메시지

스쿼시하고 병합하면 GitHub에서 편집할 수 있는 기본 커밋 메시지를 생성합니다. 기본 메시지에는 리포지토리 설정 및 끌어오기 요청의 커밋 수에 따라 끌어오기 요청 제목, 끌어오기 요청 설명 또는 커밋 정보가 포함될 수 있습니다.

유지 관리자와 관리자는 스쿼시된 커밋에 대한 기본 메시지를 구성할 수 있습니다.
[끌어오기 요청에 대한 커밋 Squash 구성](/ko/enterprise-server@3.18/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/configuring-commit-squashing-for-pull-requests)을(를) 참조하세요.

### 장기 실행 분기 Squash 및 병합

스쿼시 병합은 수명이 짧은 분기에 가장 적합합니다. Squash 병합 후 동일한 헤드 분기에서 계속 작업하는 경우 나중에 끌어오기 요청에는 이미 기본 분기에 스쿼시된 커밋이 포함될 수 있습니다. 이렇게 하면 병합 충돌이 발생할 가능성이 높아질 수 있으며 동일한 충돌을 두 번 이상 해결하도록 강제할 수 있습니다.

오랫동안 유지된 분기의 경우, 다음 풀 리퀘스트를 열기 전에 병합 커밋을 사용하거나 분기를 리베이스하는 것을 고려하세요.

## 커밋 다시 지정 및 병합

끌어오기 요청에 대한 **다시 지정 및 통합** 옵션을 선택하면 병합 커밋 없이 토픽 분기(또는 헤드 분기)의 모든 커밋이 베이스 분기에 개별적으로 추가됩니다. 이러한 방식으로 리베이스 및 병합 동작은 선형 프로젝트 히스토리를 유지하므로 [패스트포워드 병합](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.18/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/repository-roles-for-an-organization)이 있어야 하며 리포지토리에서 [다시 지정 병합을 허용](/ko/enterprise-server@3.18/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)을 참조하세요.

리베이스는 병합 커밋을 생성하지 않고 풀 리퀘스트 브랜치의 각 커밋을 기본 브랜치 위에 적용합니다. 끌어오기 요청에서 개별 커밋을 유지하면서 선형 기록을 생성합니다.

팀이 선형 기록을 원하고 끌어오기 요청 커밋이 이미 명확하게 구성된 경우 이 전략을 선택합니다.
GitHub에서 풀 리퀘스트를 자동으로 안전하게 리베이스할 수 없는 경우, 로컬에서 리베이스하고 충돌을 해결한 다음 업데이트된 브랜치를 푸시할 수 있습니다.
[Resolving a merge conflict using the command line](/ko/enterprise-server@3.18/pull-requests/how-tos/merge-and-close-pull-requests/resolving-a-merge-conflict-using-the-command-line) 및 [Merging a pull request](/ko/enterprise-server@3.18/pull-requests/how-tos/merge-and-close-pull-requests/merging-a-pull-request)을(를) 참조하세요.

## 간접 병합

풀 리퀘스트의 헤드 브랜치 커밋이 해당 풀 리퀘스트 외부에서 베이스 브랜치로부터 도달 가능해지면, 그 풀 리퀘스트는 병합된 것으로 표시될 수 있습니다. 이 문제는 동일한 커밋이 다른 끌어오기 요청을 통해 병합되거나 기본 분기에 직접 푸시될 때 발생할 수 있습니다.

간접 병합은 드물지만 자동화 및 분기 보호 기대에 영향을 줄 수 있습니다. 간접적으로 병합된 끌어오기 요청은 해당 끌어오기 요청에 대한 분기 보호 규칙이 충족되지 않은 경우에도 표시됩니다 `merged` .

## 추가 읽기

* [끌어오기 요청](/ko/enterprise-server@3.18/pull-requests/reference/pull-requests)
* [끌어오기 요청 병합 및 닫기](/ko/enterprise-server@3.18/pull-requests/how-tos/merge-and-close-pull-requests)