커밋을 병합하세요
끌어오기 요청에 대한 기본 끌어오기 요청 병합 옵션을 클릭하면 기능 분기의 모든 커밋이 병합 커밋의 베이스 분기에 추가됩니다. 끌어오기 요청은 --no-ff 옵션을 사용하여 병합됩니다.
끌어오기 요청을 병합하려면 리포지토리에 쓰기 권한이 있어야 합니다.
커밋 스쿼시 및 병합
끌어오기 요청에 대해 스쿼시 및 병합 옵션을 선택하면 끌어오기 요청의 커밋이 단일 커밋으로 스쿼시됩니다. 토픽 분기의 기여자 개별 커밋을 모두 보는 대신 커밋이 하나의 커밋으로 결합되어 기본 분기에 병합됩니다. Squah된 커밋이 있는 끌어오기 요청은 빨리 감기 옵션을 사용하여 병합됩니다.
끌어오기 요청을 Squah하고 병합하려면 리포지토리에서 쓰기 권한이 있어야 하며 리포지토리에서 Squah 병합을 허용해야 합니다.
Squash 및 병합을 사용하여 리포지토리에서 보다 간소화된 Git 기록을 만들 수 있습니다. 진행 중인 작업 커밋은 기능 분기에서 작업할 때 유용하지만 Git 기록을 보존하는 것이 반드시 필요하지는 않습니다. 기본 분기로 병합할 때 이러한 커밋을 하나의 커밋으로 스쿼시하면 변경 내용이 통합되어 명확한 Git 기록이 됩니다.
Squash 병합에 대한 병합 메시지
Squash 및 병합할 때 GitHub는 원하는 경우 편집할 수 있는 기본 커밋 메시지를 생성합니다. 리포지토리 구성 방법과 끌어오기 요청에 있는 커밋 수(병합 커밋은 제외)에 따라, 이 메시지에는 끌어오기 요청 제목, 끌어오기 요청 설명 또는 커밋 관련 정보가 포함될 수 있습니다.
| 커밋 수 | 요약 | 설명 |
|---|---|---|
| 하나의 커밋 | 단일 커밋에 대한 커밋 메시지의 제목과 끌어오기 요청 번호 | 단일 커밋에 대한 커밋 메시지의 본문 텍스트 |
| 둘 이상의 커밋 | 끌어오기 요청 제목과 끌어오기 요청 번호 | 모든 Squash된 커밋에 대한 커밋 메시지 목록(날짜 순서) |
리포지토리에 대한 유지 관리자 또는 관리자 액세스 권한이 있는 사람은 모든 스쿼시된 커밋에 대한 리포지토리의 기본 병합 메시지가 끌어오기 요청 제목만 사용하거나, 끌어오기 요청 제목 및 커밋 세부 정보를 사용하거나, 끌어오기 요청 제목 및 설명을 사용하도록 설정할 수 있습니다. 자세한 내용은 끌어오기 요청에 대한 커밋 Squash 구성을(를) 참조하세요.
장기 실행 분기 Squash 및 병합
끌어오기 요청이 병합된 후 끌어오기 요청의 헤드 분기에서 작업을 계속하려면 끌어오기 요청을 Squash하고 병합하지 않는 것이 좋습니다.
끌어오기 요청을 만들 때 GitHub은 헤드 분기와 베이스 분기 모두에 있는 가장 최근 커밋인 공통 상위 커밋을 식별합니다. 끌어오기 요청을 스쿼시하고 병합할 때, GitHub는 공통 조상 커밋 이후 헤드 브랜치에서 수행한 모든 변경 사항을 포함하는 커밋을 베이스 브랜치에 만듭니다.
이 커밋은 헤드 분기가 아닌 베이스 분기에만 있으므로 두 분기의 공통 상위 항목은 변경되지 않습니다. 헤드 분기에서 계속 작업한 다음 두 분기 간에 새 끌어오기 요청을 만들면 끌어오기 요청에는 이전 끌어오기 요청에서 Squash 및 병합한 커밋을 포함하여 공통 상위 항목 이후의 모든 커밋이 포함됩니다. 충돌이 없으면 이러한 커밋을 안전하게 병합할 수 있습니다. 그러나 이 워크플로는 병합이 충돌할 가능성을 더 높입니다. 장기 실행 헤드 분기에 대한 끌어오기 요청을 계속 Squash하고 병합하는 경우 동일한 충돌을 반복적으로 해결해야 합니다.
커밋 다시 지정 및 병합
끌어오기 요청에 대한 다시 지정 및 통합 옵션을 선택하면 병합 커밋 없이 토픽 분기(또는 헤드 분기)의 모든 커밋이 베이스 분기에 개별적으로 추가됩니다. 이러한 방식으로 다시 지정 및 병합 동작은 선형 프로젝트 기록을 유지 관리하여 빨리 감기 병합과 유사합니다. 그러나 다시 지정은 새 커밋을 사용하여 기본 분기에 커밋 기록을 다시 작성하여 이를 달성합니다.
GitHub의 다시 지정 및 병합 동작은 git rebase와 약간 다릅니다. GitHub에서의 다시 지정 및 병합은 커밋한 사람 정보를 항상 업데이트하고 새 커밋 SHA를 만듭니다. 반면에 GitHub 외부의 git rebase는 상위 커밋 위에 다시 지정이 발생할 때 커밋한 사람 정보를 변경하지 않습니다. git rebase에 대한 자세한 내용은 Git 설명서에서 git-rebase를 참조하세요.
끌어오기 요청을 다시 지정하고 병합하려면 리포지토리에서 쓰기 권한이 있어야 하며 리포지토리에서 다시 지정 병합을 허용해야 합니다.
git rebase의 시각적 표현은 Pro Git Book에서 “Git 분기 - 다시 지정” 챕터를 참조하세요.
다음과 같은 경우 자동으로 다시 지정 및 통합할 수 없습니다.
- 끌어오기 요청에 병합 충돌이 있습니다.
- 베이스 브랜치에서 헤드 브랜치로 커밋을 리베이스할 때 충돌이 발생합니다.
- 커밋을 다시 지정하는 것은 병합 충돌 없이 다시 지정이 가능하지만 병합과는 다른 결과를 생성하는 경우와 같이 “안전하지 않은” 것으로 간주됩니다.
여전히 커밋을 리베이스하고 싶지만 자동으로 리베이스 및 병합할 수 없는 경우, 다음 작업을 수행해야 합니다.
- 명령줄에서 로컬로 베이스 분기에 토픽 분기(또는 헤드 분기)를 다시 지정
-
[명령줄에서 병합 충돌을 해결합니다](/pull-requests/collaborating-with-pull-requests/addressing-merge-conflicts/resolving-a-merge-conflict-using-the-command-line). - 다시 지정된 커밋을 끌어오기 요청의 토픽 분기(또는 원격 헤드 분기)에 강제 푸시합니다.
리포지토리에서 쓰기 권한이 있는 모든 사용자는 다시 지정 및 병합 단추를 사용하여 변경 내용을 병합할 수 있습니다.
간접 병합
외부에서 헤드 브랜치가 베이스 브랜치에 직간접적으로 병합되는 경우, 해당 풀 리퀘스트는 자동 병합 처리가 가능합니다. 즉, 헤드 브랜치의 최신 커밋이 대상 브랜치의 최신 커밋으로부터 접근 가능한 상태를 의미합니다. 예시:
- 분기
main가 커밋 C에 있습니다. - 분기
feature는main에서 분기되어 현재 커밋 D에 있습니다. 이 분기는main를 대상으로 하는 풀 요청이 있습니다. - 브랜치
feature_2는feature에서 분기되어 현재 커밋 E에 있습니다. 이 브랜치는main를 대상으로 하는 풀 리퀘스트도 있습니다.
끌어오기 요청 E --> main가 먼저 병합되면 끌어오기 요청 D --> main는 모든 커밋이 이제 __ 에서 feature로 도달 가능하기 때문에 자동으로 병합된 것으로 표시됩니다. 명령줄에서 feature_2를 main로 병합하고 main를 서버로 푸시하면 두 끌어오기 요청이 모두 병합된 것으로 표시됩니다.
간접 병합은 끌어오기 요청의 헤드 분기 커밋이 리포지토리의 베이스 분기로 직접 푸시되거나 끌어오기 요청의 헤드 분기 커밋이 다른 끌어오기 요청에 있고 병합 커밋 만들기 옵션을 사용하여 리포지토리의 베이스 분기에 병합되는 경우에만 발생할 수 있습니다.
다른 끌어오기 요청의 헤드 분기에 있는 커밋이 포함된 끌어오기 요청이 Squash 및 병합 또는 다시 지정 및 병합 옵션을 사용하여 병합되는 경우 베이스 분기에 새 커밋이 생성되며 다른 끌어오기 요청은 자동으로 병합되지 않습니다.
간접적으로 병합된 끌어오기 요청은 브랜치 보호 규칙이 충족되지 않은 경우에도 merged로 표시됩니다.
추가 참고 자료
-
[AUTOTITLE](/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests) -
[AUTOTITLE](/pull-requests/collaborating-with-pull-requests/addressing-merge-conflicts)