병합 전략 및 스쿼시 병합
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
끌어오기 요청완료하면 토픽 분기를 기본 분기(일반적으로 main)에 병합합니다. 이 병합은 주 분기에 토픽 분기의 커밋을 추가하고 기본 분기와 토픽 분기 간의 충돌을 조정하는 병합 커밋을 만듭니다. 끌어오기 요청의 설명과 토론은 토픽 분기의 변경 내용에 대한 더 많은 컨텍스트를 제공합니다.
main 분기(또는 기타 기본 분기)의 커밋 기록은 관련 항목 분기 기록 때문에 직선을 따르지 않습니다. 프로젝트가 커짐에 따라 동시에 작업한 토픽 분기 수가 증가하여 기본 분기 기록을 따라하기가 점점 더 어려워집니다.
기본 분기는 각 토픽 분기의 기록을 정확하게 표현하지만 프로젝트 개발에 대한 광범위한 질문에 대답하기는 어렵습니다.
필수 조건
| 카테고리 | 요구 사항 |
|---|---|
| 프로젝트 액세스 | 프로젝트멤버입니다. |
| 권한 | - 프라이빗 프로젝트에서 코드 보기: 최소 기본 액세스. - 프라이빗 프로젝트의 코드 복제 또는 기여: 기여자 보안 그룹 또는 프로젝트의 해당 사용 권한의 구성원입니다. - 분기 또는 리포지토리 사용 권한 설정: 분기 또는 리포지토리에 대한 사용 권한 사용 권한 관리 - 기본 분기 변경: 리포지토리에 대한 정책 편집 권한 설정. - 리포지토리 가져오기: 프로젝트 관리자 보안 그룹의 구성원이거나, Git 프로젝트 수준에서 리포지토리 만들기 권한이 허용으로 설정된 경우. 자세한 내용은 Git 리포지토리 권한 설정을 참조 하세요. |
| 서비스 | 리포지토리가 활성화되었습니다. |
| 도구 | 선택 사항. az repos 명령어를 사용하세요: Azure DevOps CLI. |
비고
퍼블릭 프로젝트에서 이해 관계자 액세스 권한이 있는 사용자는 코드 보기, 복제 및 기여를 포함하여 Azure Repos에 대한 모든 권한을 갖습니다.
| 카테고리 | 요구 사항 |
|---|---|
| 프로젝트 액세스 | 프로젝트멤버입니다. |
| 권한 | - 코드 보기: 최소 베이직 접근 권한. - 코드 복제 또는 기여: 기여자 보안 그룹의 구성원이거나 프로젝트에서 해당 권한을 가진 경우. |
| 서비스 | 리포지토리가 활성화되었습니다. |
스쿼시 병합
Squash 병합은 끌어오기 요청을 완료할 때 토픽 분기의 Git 기록을 압축할 수 있는 병합 옵션입니다. 스쿼시 병합은 토픽 분기의 각 커밋을 기본 분기의 기록에 추가하는 대신 모든 파일 변경 내용을 기본 분기의 단일 새 커밋에 추가합니다. Squash 병합 커밋에는 토픽 분기에 대한 참조가 없습니다. 토픽 분기의 모든 변경 내용을 포함하는 새 커밋 생성합니다. 혼동을 방지하려면 토픽 분기를 삭제하는 것이 좋습니다.
이에 대해 생각해 볼 수 있는 간단한 방법은 squash 병합은 파일 변경 내용만 제공하고 일반 병합은 파일 변경 내용과 커밋 기록을 제공한다는 것입니다.
스쿼시 병합은 어떻게 도움이 합니까?
스쿼시 병합은 팀의 워크플로 변경을 요구하지 않고 기본 분기 기록을 정리하고 쉽게 따를 수 있도록 합니다. 토픽 분기의 기여자들은 주제 분기에서 원하는 방식으로 작업하며, 기본 분기는 squash 병합 과정을 사용하여 선형 기록을 유지합니다. squash 병합으로 업데이트된 main 분기의 커밋 기록에는 병합된 각 분기에 대해 하나의 커밋이 있습니다. 이 기록을 단계별로 실행하여 작업이 완료된 정확한 시기를 확인할 수 있습니다.
스쿼시 병합 시 고려 사항
스쿼시 병합은 기본 브랜치의 변경 기록을 압축합니다. 따라서 스쿼시 병합을 할 시기를 결정하는 것과 토픽 브랜치의 전체 커밋 기록을 유지할 시기를 팀과 함께 논의하는 것이 중요합니다. 스쿼시 병합 시 소스 브랜치를 삭제하는 것이 좋습니다. 원본 분기를 삭제하면 토픽 분기 자체에 기본 분기로 병합되는 커밋이 없으므로 혼동을 방지할 수 있습니다.
squash 병합을 사용하여 끌어오기 요청 완료
** Azure Repos에서 풀 요청을 완료할 때 스쿼시 병합을 선택할 수 있습니다.
끌어오기 요청 대화 상자에서 병합 유형 아래의 Squash 커밋을 선택하여 토픽 분기를 스쿼시 병합합니다.
여러 병합 기준
끌어오기 요청의 파일 탭은 삼중 비교를 통해 차이를 감지합니다. 알고리즘은 대상 분기의 마지막 커밋, 원본 분기의 마지막 커밋 및 공통 병합 기준(예: 가장 일반적인 공통 조상)을 고려합니다. 알고리즘은 빠르고 비용 효율적이며 신뢰할 수 있는 변경 내용 검색 방법입니다. 불행히도, 어떤 경우에는 두 개 이상의 진정한 기반이 있습니다. 대부분의 리포지토리에서 이 상황은 드물지만 활성 사용자가 많은 대규모 리포지토리에서는 일반적일 수 있습니다. 분기들 사이에 여러 개의 병합 기반이 있는지 수동으로 확인할 수 있습니다. 이렇게 하려면 git merge-base --all feature master 명령을 실행합니다. Azure DevOps는 모든 PR에 대해 여러 병합 기반이 있는지 검색합니다. 이러한 항목이 감지되면 Azure DevOps는 "여러 병합 기준이 감지되었습니다."라는 메시지를 표시합니다. PR에 대한 커밋 목록이 표시된 내용이 불완전할 수 있습니다. Azure DevOps는 여러 병합 베이스의 검색을 실행하는 동안 잠재적인 병합 기반이 이미 병합되었는지 여부를 확인하지 않습니다. 이러한 검사는 git merge-base에 의해 수행됩니다. 따라서 git merge-base 하나의 병합 베이스만 보고하는 경우에도 Azure DevOps에서 메시지를 표시할 수 있습니다.
비고
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
- 기능 분기의 활성 재사용
- 되돌리기, 체리 픽 및 병합을 사용하는 기타 비직관적이고 복잡한 조작
여러 병합 기준 감지는 보안 인식의 일환입니다. 여러 병합 기반이 있는 경우 사용자 인터페이스에 대한 파일 차이 알고리즘은 선택한 병합 기반에 따라 파일 변경 내용을 제대로 검색하지 못할 수 있습니다. 끌어오기 요청의 파일에 병합 베이스 간에 다른 버전이 있는 경우 여러 병합 기본 경고가 발생합니다.
여러 기지에서 병합할 때 발생할 수 있는 보안 위험
- 악의적인 사용자가 UI 알고리즘을 악용하여 PR에 없는 악의적인 변경 내용을 커밋할 수 있습니다.
- PR에 제안된 변경 내용이 대상 분기에 이미 있는 경우 파일 탭에 표시되지만 폴더 변경 내용에 매핑된 분기 정책을 트리거하지 않을 수 있습니다.
- 여러 병합 베이스에서 동일한 파일에 대한 두 가지 변경 내용 집합이 PR에 없을 수 있습니다. 이 경우 위험한 논리 간격이 발생할 수 있습니다.
여러 병합 베이스 문제를 해결하는 방법
여러 병합 베이스가 반드시 나쁜 것은 아니지만 모든 것이 괜찮은지 다시 확인해야 합니다. 여러 병합 베이스를 제거하기 위해서는, 분기를 대상에 리베이스하거나 또는 대상을 분기에 병합하여 분기를 단일한 공통 조상에 연결하세요. 이러한 작업은 경고 메시지를 제거하고 실제 변경 내용이 올바른지 확인하는 데 도움이 됩니다.
한 가지 방법은 리베이스나 병합하기 전에 소프트 리셋을 하고 진행 상태를 임시로 보관하는 것입니다. 그런 다음 새 분기를 만들거나 빈 분기를 다시 지정하고 명확한 지점에서 변경 내용을 적용할 수 있습니다. 변경 내용이 이미 있는 경우 이 프로세스를 원격으로 강제 푸시해야 할 수 있습니다.
여러 병합 기본 문제를 방지하는 방법
다음은 여러 병합 기본 문제를 방지하기 위한 일반적인 팁입니다.
- 끌어오기 요청을 준비할 때, 가장 최신 버전의 main 또는 release 브랜치에서 기능 브랜치를 만드세요.
- 필요한 경우가 아니면 리포지토리의 안정적인 분기에서 직접 시작되지 않는 분기를 만들지 마세요.
여러 병합 기반 문제가 다시 나타나는 경우 수행할 작업
많은 활성 기여자가 있는 대규모 리포지토리에서 이 문제는 특히 불편할 수 있습니다. 병합을 통해 여러 베이스를 제거하더라도 상황이 다시 나타날 수 있습니다. 누군가가 오랜 끌어오기 요청을 닫으면 상황을 다시 만들 수 있습니다. 빌드 정책 및 테스트가 실행되고 있더라도 끌어오기 요청을 완료할 수 있는 방법은 없습니다. 새 분기를 다시 설정 및 시작하는 것이 도움이 될 수 있습니다. 변경된 내용이 없는 경우 상황이 반복되더라도 변경 내용이 명확할 수 있습니다.