병합 전략 및 스쿼시 병합
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
끌어오기 요청을 완료하면 일반적으로 토픽 분기를 기본 분기 병합합니다main. 이 병합은 기본 분기에 토픽 분기의 커밋을 추가하고 기본 분기와 토픽 분기 간의 충돌을 조정하는 병합 커밋을 만듭니다. 끌어오기 요청의 설명과 토론은 토픽 분기의 변경 내용에 대한 추가 컨텍스트를 제공합니다.
관련 토픽 분기 기록 때문에 분기(또는 기타 기본 분기)의 커밋 기록은 main 직선을 따르지 않습니다. 프로젝트가 커짐에 따라 동시에 작업한 토픽 분기 수가 증가하여 기본 분기 기록을 따라하기가 점점 더 어려워집니다.
기본 분기 각 토픽 분기의 기록을 정확하게 표현하지만 프로젝트 개발에 대한 광범위한 질문에 대답하기는 어렵습니다.
Squash 병합
Squash 병합은 끌어오기 요청을 완료할 때 토픽 분기의 Git 기록을 압축할 수 있는 병합 옵션입니다. 토픽 분기의 각 커밋이 기본 분기 기록에 추가되는 대신, 스쿼시 병합은 모든 파일 변경 내용을 기본 분기 단일 새 커밋에 추가합니다. Squash 병합 커밋에는 토픽 분기에 대한 참조가 없으며 토픽 분기의 모든 변경 내용을 포함하는 새 커밋이 생성됩니다. 또한 혼동을 방지하기 위해 토픽 분기를 삭제하는 것이 좋습니다.
이에 대해 생각해 볼 수 있는 간단한 방법은 스쿼시 병합은 파일 변경 내용만 제공하고 일반 병합은 파일 변경 내용과 커밋 기록을 제공한다는 것입니다.
스쿼시 병합은 어떻게 도움이 나요?
스쿼시 병합은 팀의 워크플로 변경을 요구하지 않고도 기본 분기 기록을 클린 따라하기 쉽습니다. 토픽 분기에 대한 기여자는 토픽 분기에서 원하는 방식으로 작업하고 기본 분기 스쿼시 병합을 사용하여 선형 기록을 유지합니다. 스쿼시 병합으로 업데이트된 분기의 main 커밋 기록에는 병합된 각 분기에 대해 하나의 커밋이 있습니다. 이 기록을 단계별로 실행하여 작업이 완료된 정확한 시기를 확인할 수 있습니다.
스쿼시 병합 시 고려 사항
스쿼시 병합은 기본 분기 변경 기록을 압축하므로 팀과 협력하여 병합할 스쿼시 시기 또는 토픽 분기의 전체 커밋 기록을 유지할 시기를 결정하는 것이 중요합니다. 스쿼시 병합할 때 원본 분기를 삭제하는 것이 좋습니다. 원본 분기를 삭제하면 토픽 분기 자체에 커밋이 기본 분기 병합되지 않으므로 혼동을 방지할 수 있습니다.
스쿼시 병합을 사용하여 끌어오기 요청 완료
Azure Repos에서 끌어오기 요청을 완료할 때 병합을 스쿼시 선택할 수 있습니다.
끌어오기 요청 완료 대화 상자에서 병합 형식 아래에서 Squash 커밋을 선택하여 토픽 분기를 병합할 스쿼시.
여러 병합 기준
끌어오기 요청의 파일 탭은 3면 비교를 통해 차이 감지합니다. 알고리즘은 대상 분기의 마지막 커밋, 원본 분기의 마지막 커밋 및 공통 병합 기반 (즉, 가장 일반적인 상위 항목)을 고려합니다. 알고리즘은 빠르고 비용 효율적이며 신뢰할 수 있는 변경 내용 검색 방법입니다. 불행히도, 어떤 경우에는 두 개 이상의 진정한 기반이 있습니다. 대부분의 리포지토리에서 이 상황은 드물지만 활성 사용자가 많은 대규모 리포지토리에서는 일반적일 수 있습니다. 분기 사이에 여러 병합 기반이 있는 경우 수동으로 검사 수 있습니다. 이렇게 하려면 명령을 실행 git merge-base --all feature master 합니다. Azure DevOps는 모든 PR에 대해 여러 병합 기반이 있는지 검색합니다. 이러한 항목이 검색되면 Azure DevOps는 "여러 병합 기반이 검색되었습니다. 표시된 커밋 목록은 불완전할 수 있습니다." PR에 대한 설명입니다. Azure DevOps가 여러 병합 베이스의 검색을 실행하는 동안 잠재적인 병합 기반이 이미 병합되었는지 여부는 검사 않습니다. 이러한 검사 수행git merge-base됩니다. 따라서 Azure DevOps는 하나의 병합 기반만 보고하는 경우에도 git merge-base 메시지를 표시할 수 있습니다.
참고 항목
PR 검토 중에 변경 내용이 손실된 경우 여러 병합 기반이 근본 원인이 아닌지 확인하세요.
다음 시나리오는 Azure DevOps에서 여러 밑으로 검색됩니다(병합 베이스는 숫자 1과 2로 표시됨).
- 서로 다른 분기 간의 교차 병합(criss-cross라고도 함) (Azure DevOps에서
git merge-base보고됨)
---1---o---A
\ /
X
/ \
---2---o---o---B
- 한 분기를 다른 두 분기로 병합(Azure DevOps에서 보고하지만 병합 기본 2를 제거하지 않음
git merge-base)
---1---o---o---o---A
\ /
\-------2
\ \
\---o---o---o---B
- 기본 분기 되돌리기 여파 처리(예: 병합 커밋 수정)
* 42bb2d2 (HEAD, A) Amended merge commit
|\
| | * 67c9bb8 (other) Merge branch 'A' into B
| | |\
| |/ /
|/| /
| |/
| * fa78e32 add second commit
* | 15845c9 add first commit
|/
* 6a52130 add init
- 기능 분기 활성 다시 사용
- 되돌리기, 체리 픽 및 병합을 사용하는 기타 비직관적이고 혼잡한 조작
여러 병합 기본 검색은 보안 인식의 일부입니다. 여러 병합 기반이 있는 경우 사용자 인터페이스에 대한 파일 차이 알고리즘은 선택한 병합 기반에 따라 파일 변경 내용을 제대로 검색하지 못할 수 있습니다. 끌어오기 요청의 파일에 병합 베이스 간에 다른 버전이 있는 경우 여러 병합 기본 경고가 발생합니다.
자세한 내용은 공식 git 설명서를 검토하세요.
여러 기지에서 병합할 때 발생할 수 있는 보안 위험
- 악의적인 사용자가 UI 알고리즘을 악용하여 PR에 없는 악의적인 변경 내용을 커밋할 수 있습니다.
- PR에서 제안된 변경 내용이 대상 분기에 이미 있는 경우 파일 탭에 표시되지만 폴더 변경 내용에 매핑된 분기 정책을 트리거하지 않을 수 있습니다.
- 여러 병합 베이스에서 동일한 파일에 대한 두 가지 변경 내용 집합이 PR에 없을 수 있습니다. 이 경우 위험한 논리 간격이 발생할 수 있습니다.
여러 병합 기본 문제를 해결하는 방법
여러 병합 베이스를 갖는 것이 반드시 나쁜 것은 아니지만 모든 것이 괜찮다는 것을 두 번 검사 합니다. 여러 병합 베이스를 제거하려면 대상에서 분기를 다시 적용하거나 대상을 분기에 병합하여 분기를 단일 공통 상위 항목에 연결합니다. 이러한 작업은 경고 메시지를 제거하고 실제 변경 내용이 올바른지 검사 데 도움이 됩니다.
한 가지 방법은 재지정 또는 병합하기 전에 진행률을 일시 재설정하고 숨기는 것입니다. 그런 다음 새 분기를 만들거나 빈 분기를 다시 지정하고 명확한 지점에서 변경 내용을 적용할 수 있습니다. 이 프로세스는 변경 내용이 이미 있는 경우 원격으로 강제 푸시 필요할 수 있습니다.
여러 병합 기본 문제를 방지하는 방법
다음은 여러 병합 기본 문제를 방지하기 위한 일반적인 팁입니다.
- 끌어오기 요청을 준비할 때 최신 버전의 기본 또는 릴리스 분기에서 기능 분기 만듭니다.
- 필요한 경우가 아니면 리포지토리의 안정적인 분기에서 직접 시작되지 않는 분기를 만들지 마세요.
여러 병합 기반 문제가 다시 나타나는 경우 수행할 작업
많은 활성 기여자 있는 대규모 리포지토리에서 이 문제는 특히 불편할 수 있습니다. 병합을 통해 여러 베이스를 제거하더라도 상황이 다시 나타날 수 있습니다. 누군가가 오랜 끌어오기 요청을 닫으면 상황을 다시 만들 수 있습니다. 빌드 정책 및 테스트가 실행되고 있더라도 끌어오기 요청을 완료할 수 있는 방법은 없습니다. 새 분기를 다시 설정 및 시작하는 것이 도움이 될 수 있습니다. 변경된 내용이 없는 경우 상황이 반복되더라도 변경 내용이 명확할 수 있습니다.