GitHub에서의 병합 메서드 정보

Git 기록을 관리하기 위한 워크플로 요구 사항 및 기본 설정을 충족하도록 GitHub.com에서 끌어오기 요청 병합 옵션을 구성할 수 있습니다. 자세한 내용은 "끌어오기 요청 병합 구성"을 참조하세요. 리포지토리에 대해 원하는 메서드만 사용하도록 설정하여 커밋 Squash 또는 다시 지정 같은 병합 메서드의 한 가지 유형을 적용할 수 있습니다.

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

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

기본 병합 메서드는 병합 커밋을 만듭니다. 선형 커밋 기록을 적용함으로써 아무나 보호된 분기에 병합 커밋을 푸시하지 못하게 할 수 있습니다. 자세한 내용은 "보호된 분기 정보"을(를) 참조하세요.

병합 커밋 Squash하기

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

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

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

커밋 Squash를 사용하도록 설정하기 전에 다음과 같은 단점을 고려하세요.

• 특정 변경이 원래 언제 이루어졌으며 누가 Squash된 커밋을 작성했는지에 대한 정보가 손실됩니다.
• Squash 및 병합 후 끌어오기 요청의 헤드 분기에 대한 작업을 계속한 다음 동일한 분기 간에 새 끌어오기 요청을 만드는 경우, 이전에 Squash하고 병합한 커밋이 새 끌어오기 요청에 나열됩니다. 또한 각 연속 끌어오기 요청에서 반복적으로 해결해야 하는 충돌이 있을 수 있습니다. 자세한 내용은 "끌어오기 요청 병합 정보"을(를) 참조하세요.
• 원래 커밋에 대한 SHA ID가 손실되므로 “SHA” 또는 “hash” ID를 사용하는 일부 Git 명령은 사용하기가 더 어려울 수 있습니다. 예를 들어 git rerere 사용은 효과적이지 않을 수 있습니다.

자세한 내용은 "끌어오기 요청에 대한 커밋 Squash 구성"을(를) 참조하세요.

커밋 다시 지정 및 병합

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

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

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

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

커밋 다시 지정을 사용하도록 설정하기 전에 다음과 같은 단점을 고려하세요.

• 리포지토리 기여자는 GitHub.com에서 다시 지정 및 병합 옵션을 사용하기 전에 명령줄에서 다시 지정하고, 충돌을 해결하고, 변경 내용을 끌어오기 요청의 토픽 분기(또는 원격 헤드 분기)에 강제로 푸시해야 할 수 있습니다. 다른 사용자가 기반으로 하는 작업을 기여자가 덮어쓰지 않도록 강제 푸시는 신중하게 수행해야 합니다. GitHub.com에서 다시 지정 및 병합 옵션이 사용되지 않는 경우 및 이를 다시 사용하도록 설정하는 워크플로에 대한 자세한 내용은 "끌어오기 요청 병합 정보"을(를) 참조하세요.

• 끌어오기 요청에서 다시 지정 및 병합 옵션을 사용하는 경우 커밋 서명 확인 없이 헤드 분기의 커밋이 기본 분기에 추가된다는 점에 유의해야 합니다. 이 옵션을 사용하면 GitHub는 원래 커밋의 데이터와 콘텐츠를 사용하여 수정된 커밋을 만듭니다. 즉, GitHub는 이 커밋을 실제로 만들지 않았으므로 일반 시스템 사용자로 서명할 수 없습니다. GitHub는 커밋자의 프라이빗 서명 키에 액세스할 수 없으므로 사용자를 대신하여 커밋에 서명할 수 없습니다.

  이에 대한 해결 방법은 로컬로 다시 지정 및 병합한 다음 변경 내용을 끌어오기 요청의 기본 분기로 푸시하는 것입니다.

자세한 내용은 "끌어오기 요청에 대한 커밋 다시 지정 구성"을(를) 참조하세요.