끌어오기 요청은 여러 가지 방법으로 병합할 수 있습니다. 최상의 전략은 팀이 리포지토리 기록을 찾는 방법과 끌어오기 요청 분기에서 유지할 세부 정보 양에 따라 달라집니다.
| Strategy | Result | 시기 선택 |
|---|---|---|
| 병합 커밋 | 끌어오기 요청 분기의 모든 커밋을 유지하고 명시적 병합 지점을 추가합니다. | 팀에서 전체 이력을 중요하게 여기거나, 개별 커밋 하나하나가 그 자체로 의미가 있습니다. |
| 스쿼시 및 병합 | 끌어오기 요청의 모든 커밋을 기본 분기의 단일 커밋으로 결합합니다. | 풀 리퀘스트는 하나의 논리적 변경을 나타내며, 특히 자잘한 수정 커밋이 많은 경우에 더욱 그렇습니다. |
| 다시 기반 및 병합 | 선형 기록을 유지하기 위해 병합 커밋 없이 각 커밋을 베이스 브랜치에 차례로 적용합니다. | 팀은 선형 기록을 원하고 커밋은 이미 명확하게 구성되어 있습니다. |
커밋을 병합하세요
끌어오기 요청에 대한 기본 끌어오기 요청 병합 옵션을 클릭하면 기능 분기의 모든 커밋이 병합 커밋의 베이스 분기에 추가됩니다. 끌어오기 요청은 --no-ff 옵션을 사용하여 병합됩니다.
끌어오기 요청을 병합하려면 리포지토리에 쓰기 권한이 있어야 합니다.
병합 커밋은 끌어오기 요청 분기의 전체 커밋 기록을 유지합니다. 이렇게 하면 검토 수정 및 중간 작업을 포함하여 최종 변경으로 이어진 모든 커밋을 더 쉽게 볼 수 있습니다. 또한 기본 분기 기록에 명시적 병합 지점을 만듭니다.
팀이 전체 기록을 중요하게 여기거나 풀 리퀘스트의 개별 커밋 자체로 의미가 있는 경우 이 전략을 선택합니다.
커밋을 스쿼시한 후 병합
끌어오기 요청에 대해 스쿼시 및 병합 옵션을 선택하면 끌어오기 요청의 커밋이 단일 커밋으로 스쿼시됩니다. 토픽 분기의 기여자 개별 커밋을 모두 보는 대신 커밋이 하나의 커밋으로 결합되어 기본 분기에 병합됩니다. Squah된 커밋이 있는 끌어오기 요청은 빨리 감기 옵션을 사용하여 병합됩니다.
끌어오기 요청을 Squah하고 병합하려면 리포지토리에서 쓰기 권한이 있어야 하며 리포지토리에서 Squah 병합을 허용해야 합니다.
Squash 및 병합을 사용하여 리포지토리에서 보다 간소화된 Git 기록을 만들 수 있습니다. 진행 중인 작업 커밋은 기능 분기에서 작업할 때 유용하지만 Git 기록을 보존하는 것이 반드시 필요하지는 않습니다. 기본 분기로 병합할 때 이러한 커밋을 하나의 커밋으로 스쿼시하면 변경 내용이 통합되어 명확한 Git 기록이 됩니다.
스쿼시는 끌어오기 요청의 모든 커밋을 기본 분기의 하나의 커밋으로 바꿉니다. 이렇게 하면 기본 분기 기록이 간결하게 유지되며 나중에 더 쉽게 검색할 수 있습니다. 대신 풀 리퀘스트의 중간 커밋은 기반 브랜치에 개별 커밋으로 보존되지 않습니다.
끌어오기 요청이 하나의 논리적 변경 내용을 나타내는 경우, 특히 분기에 작은 수정 커밋이 많은 경우 이 전략을 선택합니다.
Squash 병합에 대한 병합 메시지
스쿼시하고 병합하면 GitHub에서 편집할 수 있는 기본 커밋 메시지를 생성합니다. 기본 메시지에는 리포지토리 설정 및 끌어오기 요청의 커밋 수에 따라 끌어오기 요청 제목, 끌어오기 요청 설명 또는 커밋 정보가 포함될 수 있습니다.
유지 관리자와 관리자는 스쿼시된 커밋에 대한 기본 메시지를 구성할 수 있습니다. 끌어오기 요청에 대한 커밋 Squash 구성을(를) 참조하세요.
장기 실행 분기 Squash 및 병합
스쿼시 병합은 수명이 짧은 분기에 가장 적합합니다. Squash 병합 후 동일한 헤드 분기에서 계속 작업하는 경우 나중에 끌어오기 요청에는 이미 기본 분기에 스쿼시된 커밋이 포함될 수 있습니다. 이렇게 하면 병합 충돌이 발생할 가능성이 높아질 수 있으며 동일한 충돌을 두 번 이상 해결하도록 강제할 수 있습니다.
오랫동안 유지된 분기의 경우, 다음 풀 리퀘스트를 열기 전에 병합 커밋을 사용하거나 분기를 리베이스하는 것을 고려하세요.
커밋 다시 지정 및 병합
끌어오기 요청에 대한 다시 지정 및 통합 옵션을 선택하면 병합 커밋 없이 토픽 분기(또는 헤드 분기)의 모든 커밋이 베이스 분기에 개별적으로 추가됩니다. 이러한 방식으로 리베이스 및 병합 동작은 선형 프로젝트 히스토리를 유지하므로 패스트포워드 병합과 유사합니다. 그러나 다시 지정은 새 커밋을 사용하여 기본 분기에 커밋 기록을 다시 작성하여 이를 달성합니다.
GitHub 외부에서는 GitHub에서의 리베이스 및 병합 동작이 git rebase와 약간 다릅니다.
GitHub에서 리베이스 및 병합:
- 항상 커밋자 정보를 업데이트하고 새 커밋 SHA를 만드는 반면
git rebase, 상위 커밋 위에 다시 기반이 발생할 때 커밋 정보를 변경하지는 않습니다. - 처음에는 비어 있던 커밋(예: 만든
git commit --allow-empty커밋)을 삭제하는 반면git rebase, 기본적으로 원래 비어 있는 커밋은 유지됩니다.
git rebase에 대한 자세한 내용은 Git 설명서에서 git-rebase를 참조하세요.
끌어오기 요청을 다시 지정하고 병합하려면 리포지토리에서 쓰기 권한이 있어야 하며 리포지토리에서 다시 지정 병합을 허용해야 합니다.
git rebase의 시각적 표현은 Pro Git 책의 "Git Branching - Rebasing" 장을 참조하세요.
리베이스는 병합 커밋을 생성하지 않고 풀 리퀘스트 브랜치의 각 커밋을 기본 브랜치 위에 적용합니다. 끌어오기 요청에서 개별 커밋을 유지하면서 선형 기록을 생성합니다.
팀이 선형 기록을 원하고 끌어오기 요청 커밋이 이미 명확하게 구성된 경우 이 전략을 선택합니다. GitHub에서 풀 리퀘스트를 자동으로 안전하게 리베이스할 수 없는 경우, 로컬에서 리베이스하고 충돌을 해결한 다음 업데이트된 브랜치를 푸시할 수 있습니다. Resolving a merge conflict using the command line 및 Merging a pull request을(를) 참조하세요.
간접 병합
풀 리퀘스트의 헤드 브랜치 커밋이 해당 풀 리퀘스트 외부에서 베이스 브랜치로부터 도달 가능해지면, 그 풀 리퀘스트는 병합된 것으로 표시될 수 있습니다. 이 문제는 동일한 커밋이 다른 끌어오기 요청을 통해 병합되거나 기본 분기에 직접 푸시될 때 발생할 수 있습니다.
간접 병합은 드물지만 자동화 및 분기 보호 기대에 영향을 줄 수 있습니다. 간접적으로 병합된 끌어오기 요청은 해당 끌어오기 요청에 대한 분기 보호 규칙이 충족되지 않은 경우에도 표시됩니다 merged .