끌어오기 요청 병합 정보

커밋 병합

GitHub Enterprise Server 인스턴스의 끌어오기 요청에서 기본 병합 끌어오기 요청 옵션을 클릭하면 기능 분기의 모든 커밋이 병합 커밋의 기본 분기에 추가됩니다. 끌어오기 요청은 --no-ff 옵션을 사용하여 병합됩니다.

끌어오기 요청을 병합하려면 리포지토리에 쓰기 권한이 있어야 합니다.

커밋 스쿼시 및 병합

GitHub Enterprise Server 인스턴스의 끌어오기 요청에서 Squash 및 병합 옵션을 선택하면 끌어오기 요청의 커밋이 단일 커밋으로 스쿼시됩니다. 토픽 분기의 기여자 개별 커밋을 모두 보는 대신 커밋이 하나의 커밋으로 결합되어 기본 분기에 병합됩니다. Squah된 커밋이 있는 끌어오기 요청은 빨리 감기 옵션을 사용하여 병합됩니다.

끌어오기 요청을 Squah하고 병합하려면 리포지토리에서 쓰기 권한이 있어야 하며 리포지토리에서 Squah 병합을 허용해야 합니다.

Squash 및 병합을 사용하여 리포지토리에서 보다 간소화된 Git 기록을 만들 수 있습니다. 진행 중인 작업 커밋은 기능 분기에서 작업할 때 유용하지만 Git 기록을 보존하는 것이 반드시 필요하지는 않습니다. 기본 분기에 병합하는 동안 이러한 커밋을 하나의 커밋으로 Squash하는 경우 명확한 Git 기록으로 원래 변경 내용을 보존할 수 있습니다.

Squash 병합에 대한 병합 메시지

Squash 및 병합할 때 GitHub에서는 사용자가 편집할 수 있는 기본 커밋 메시지를 생성합니다. 기본 메시지는 끌어오기 요청의 커밋 수에 따라 달라지며 병합 커밋은 포함하지 않습니다.

커밋 수	요약	Description
하나의 커밋	단일 커밋에 대한 커밋 메시지의 제목과 끌어오기 요청 번호	단일 커밋에 대한 커밋 메시지의 본문 텍스트
둘 이상의 커밋	끌어오기 요청 제목과 끌어오기 요청 번호	모든 Squash된 커밋에 대한 커밋 메시지 목록(날짜 순서)

커밋 수	요약	Description
하나의 커밋	단일 커밋에 대한 커밋 메시지의 제목과 끌어오기 요청 번호	단일 커밋에 대한 커밋 메시지의 본문 텍스트
둘 이상의 커밋	끌어오기 요청 제목과 끌어오기 요청 번호	모든 Squash된 커밋에 대한 커밋 메시지 목록(날짜 순서)

장기 실행 분기 Squash 및 병합

끌어오기 요청이 병합된 후 끌어오기 요청의 헤드 분기에서 작업을 계속하려면 끌어오기 요청을 Squash하고 병합하지 않는 것이 좋습니다.

끌어오기 요청을 만들 때 GitHub은 헤드 분기와 베이스 분기 모두에 있는 가장 최근 커밋인 공통 상위 커밋을 식별합니다. 끌어오기 요청을 Squash하고 병합할 때 GitHub는 공통 상위 커밋 이후 헤드 분기에서 수행한 모든 변경 내용을 포함하는 커밋을 베이스 분기에 만듭니다.

이 커밋은 헤드 분기가 아닌 베이스 분기에만 있으므로 두 분기의 공통 상위 항목은 변경되지 않습니다. 헤드 분기에서 계속 작업한 다음 두 분기 간에 새 끌어오기 요청을 만들면 끌어오기 요청에는 이전 끌어오기 요청에서 Squash 및 병합한 커밋을 포함하여 공통 상위 항목 이후의 모든 커밋이 포함됩니다. 충돌이 없으면 이러한 커밋을 안전하게 병합할 수 있습니다. 그러나 이 워크플로는 병합이 충돌할 가능성을 더 높입니다. 장기 실행 헤드 분기에 대한 끌어오기 요청을 계속 Squash하고 병합하는 경우 동일한 충돌을 반복적으로 해결해야 합니다.

커밋 다시 지정 및 병합

GitHub Enterprise Server 인스턴스의 끌어오기 요청에서 다시 지정 및 병합 옵션을 선택하면 항목 분기(또는 헤드 분기)의 모든 커밋이 병합 커밋 없이 개별적으로 기본 분기에 추가됩니다. 이러한 방식으로 다시 지정 및 병합 동작은 선형 프로젝트 기록을 유지 관리하여 빨리 감기 병합과 유사합니다. 그러나 다시 지정은 새 커밋을 사용하여 기본 분기에 커밋 기록을 다시 작성하여 이를 달성합니다.

GitHub Enterprise Server의 다시 지정 및 병합 동작은 git rebase와 약간 다릅니다. GitHub에서의 다시 지정 및 병합은 커밋한 사람 정보를 항상 업데이트하고 새 커밋 SHA를 만듭니다. 반면에 GitHub 외부의 git rebase는 상위 커밋 위에 다시 지정이 발생할 때 커밋한 사람 정보를 변경하지 않습니다. git rebase에 대한 자세한 내용은 Git 설명서에서 git-rebase를 참조하세요.

끌어오기 요청을 다시 지정하고 병합하려면 리포지토리에서 쓰기 권한이 있어야 하며 리포지토리에서 다시 지정 병합을 허용해야 합니다.

git rebase의 시각적 표현은 Pro Git Book에서 “Git 분기 - 다시 지정” 챕터를 참조하세요.

다음과 같은 경우 GitHub Enterprise Server 인스턴스에 자동으로 다시 지정하고 병합할 수 없습니다.

• 끌어오기 요청에 병합 충돌이 있습니다.
• 베이스 분기에서 헤드 분기로 커밋을 다시 실행하면 충돌이 실행됩니다.
• 커밋을 다시 지정하는 것은 병합 충돌 없이 다시 지정이 가능하지만 병합과는 다른 결과를 생성하는 경우와 같이 “안전하지 않은” 것으로 간주됩니다.

여전히 커밋을 다시 지정하려고 하지만 GitHub Enterprise Server 인스턴스에서 자동으로 다시 지정하고 병합할 수 없는 경우 다음을 수행해야 합니다.

• 명령줄에서 로컬로 베이스 분기에 토픽 분기(또는 헤드 분기)를 다시 지정
• 명령줄에서 병합 충돌을 해결합니다.
• 다시 지정된 커밋을 끌어오기 요청의 토픽 분기(또는 원격 헤드 분기)에 강제 푸시합니다.

리포지토리에 쓰기 권한이 있는 사용자는 GitHub Enterprise Server 인스턴스의 다시 지정 및 병합 단추를 사용하여 변경 내용을 병합 할 수 있습니다.

간접 병합

헤드 분기가 외부적으로 기본 분기에 직접 또는 간접적으로 병합되는 경우 끌어오기 요청을 자동으로 병합할 수 있습니다. 즉, 대상 분기의 끝에서 헤드 분기의 팁 커밋에 연결할 수 있게 되면 입니다. 예를 들면 다음과 같습니다.

• 분기 main 가 커밋 C에 있습니다.
• 분기 feature 가 에서 main 분기되었으며 현재 커밋 D에 있습니다. 이 분기에는 를 대상으로 하는 끌어오기 요청이 있습니다 main.
• 분기 feature_2 가 에서 feature 분기되고 이제 커밋 E에 있습니다. 이 분기에는 를 대상으로 하는 끌어오기 요청도 있습니다 main.

끌어오기 요청 E --> main가 먼저 병합되면 의 모든 커밋 feature 에 연결할 수 main있으므로 끌어오기 요청 D --> main가 자동으로 병합된 것으로 표시됩니다. 명령줄에서 으로 main 병합 feature_2 하고 서버로 푸시 main 하면 두 끌어오기 요청이 모두 병합된 것으로 표시됩니다.

이 상황에서 끌어오기 요청은 분기 보호 규칙이 충족되지 않은 경우에도 로 merged 표시됩니다.

추가 참고 자료

• "끌어오기 요청 정보"
• "병합 충돌 처리"