기본 분기 변경

2025-04-05

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

기본 분기는 Git이 새 클론에서 체크 아웃할 첫 번째 분기입니다. 또한, 풀 요청은 기본적으로 이 브랜치를 대상으로 합니다.

기본 분기를 변경하는 과정을 살펴보겠습니다. 또한 이 변경을 수행할 때 고려해야 할 다른 사항 및 업데이트에 대해서도 설명합니다. 마지막으로 전환을 완화하기 위한 도구를 살펴보겠습니다.

필수 조건

카테고리	요구 사항
프로젝트 액세스	프로젝트멤버입니다.
권한	- 프라이빗 프로젝트에서 코드 보기: 최소 기본 액세스. - 프라이빗 프로젝트의 코드 복제 또는 기여: 기여자 보안 그룹 또는 프로젝트의 해당 사용 권한의 구성원입니다. - 분기 또는 리포지토리 사용 권한 설정: 분기 또는 리포지토리에 대한 사용 권한 사용 권한 관리 - 기본 분기 변경: 리포지토리에 대한 정책 편집 권한 설정. - 리포지토리 가져오기: 프로젝트 관리자 보안 그룹의 구성원이거나, Git 프로젝트 수준에서 리포지토리 만들기 권한이 허용으로 설정된 경우. 자세한 내용은 Git 리포지토리 권한 설정을 참조 하세요.
서비스	리포지토리가 활성화되었습니다.
도구	선택 사항입니다. az repos 명령을 사용합니다. Azure DevOps CLI.

비고

퍼블릭 프로젝트에서 이해 관계자 액세스 권한이 있는 사용자는 코드 보기, 복제 및 기여를 포함하여 Azure Repos에 대한 모든 권한을 갖습니다.

카테고리	요구 사항
프로젝트 액세스	프로젝트멤버입니다.
권한	- 코드 보기: 최소 베이직 접근 권한. - 코드 복제 또는 기여: 기여자 보안 그룹의 구성원이거나 프로젝트에서 해당 권한을 가진 경우.
서비스	리포지토리가 활성화되었습니다.

새 기본 분기 설정

새로운 변경 사항을 위해 main 이외의 브랜치를 사용하거나 리포지토리에서 주 개발 라인을 변경할 수 있습니다. 새 리포지토리의 기본 분기 이름을 변경하려면 모든 리포지토리 설정 및 정책을 참조하세요.

새 끌어오기 요청을 병합하기 위해 리포지토리의 기본 분기를 변경하려면 두 개 이상의 분기가 필요합니다. 분기가 하나만 있는 경우 이미 기본값입니다. 기본값을 변경하려면 두 번째 분기를 만들어야 합니다.

비고

기본 분기를 변경하려면 정책 편집 권한이 있어야 합니다. 자세한 내용은 Git 리포지토리 권한 설정을 참조 하세요.

프로젝트 리포지토리에서 분기를 선택합니다.
분기 페이지에서 원하는 새 기본 분기 옆에 있는 추가 옵션을 선택하고 기본 분기로 설정을 선택합니다.
새 기본 분기를 설정한 후 원하는 경우 이전 기본값을 삭제할 수 있습니다.

이 변경을 하기 전에 고려해야 할 다른 측면이 있습니다.

이름 선택

Git 2.28 은 초기 분기 이름을 선택하는 기능을 추가했습니다. 동시에 Azure Repos, GitHub 및 기타 Git 호스팅 공급자는 다른 초기 분기 이름을 선택할 수 있는 기능을 추가했습니다. 이전에는 기본 분기의 이름이 거의 항상 지정 master되었습니다. 가장 인기 있는 대체 이름은 main. 덜 일반적인 옵션은 trunk 및 development입니다. 사용 중인 도구나 팀의 제한 사항이 없으면 유효한 분기 이름을 사용할 수 있습니다.

다른 시스템 업데이트

다른 기본 분기로 변경하면 워크플로의 다른 부분이 영향을 받을 수 있습니다. 변경을 계획할 때 이러한 부분을 고려해야 합니다.

파이프라인

모든 파이프라인에 대한 CI 트리거 를 업데이트합니다. 디자이너 파이프라인은 웹에서 편집할 수 있습니다. YAML 파이프라인은 해당 리포지토리에서 편집할 수 있습니다.

기내 끌어오기 요청

열려 있는 각 끌어오기 요청을 새로운 기본 브랜치로 설정합니다.

기존 클론

리포지토리의 새 복제본은 새 기본 분기를 가져옵니다. 전환 후, 기존 클론을 가진 모든 사용자는 자신의 원격 기본 분기 보기를 업데이트하기 위해 git remote set-head origin -a 명령을 실행해야 합니다. 만약 다른 이름을 사용한다면, origin을 원격의 이름으로 교체하십시오. 이후의 새 분기는 새 기본값을 기반으로 해야 합니다.

들어오는 링크

Azure Repos의 파일을 가리키는 일부 책갈피, 문서 및 기타 비 코드 파일을 업데이트해야 합니다. 파일 또는 디렉터리의 분기 이름은 URL에 표시할 수 있습니다.

예를 들어 &version=GBmybranchnameURL에 대한 version쿼리 문자열이 포함된 경우 해당 URL을 업데이트해야 합니다. 다행히 기본 분기에 대한 대부분의 링크에는 version 세그먼트가 포함되지 않으므로 as-is그대로 두어도 됩니다. 또한 이전 기본 브랜치를 삭제하면 그 브랜치로 탐색하려는 시도는 새 기본 브랜치로 이동됩니다.

임시 미러링

Git 리포지토리에는 하나의 기본 분기만 있을 수 있습니다. 그러나 잠시 동안 이전 기본값과 새 기본값 간에 임시 미러링을 설정할 수 있습니다. 이렇게 하면 최종 사용자가 계속해서 이전 기본값으로 푸시하는 경우 작업을 다시 실행하지 않아도 됩니다. Azure Pipelines를 사용하여 이 임시 미러링을 설정합니다.

비고

이 섹션에서는 Microsoft의 관점과 상충되는 언어를 사용합니다. 특히 이 단어 master 는 Git에서 사용된 방법과 일치하는 여러 위치에 나타납니다. 이 항목의 목적은 다음과 같이 main더 포괄적인 언어로 전환하는 방법을 설명하는 것입니다. master에 대한 모든 언급을 생략하면 지침을 이해하기가 훨씬 어려워집니다.

미러링 파이프라인

비고

이러한 지침은 속지 않으며 리포지토리 설정에 사용 권한 및 정책 완화와 같은 추가 변경이 필요할 수 있습니다.

경고

이 파이프라인을 실행하기 전에 이전 분기와 새 기본 분기가 모두 업데이트된 경우 파이프라인은 변경 내용을 미러링할 수 없습니다. 누군가가 자동으로 다시 실행되도록 이전 기본 분기를 새 기본 분기에 수동으로 병합 해야 합니다.

모든 기존 CI 빌드를 이전 분기가 아닌 새 기본 분기에 대해 트리거 하도록 업데이트하세요.
리포지토리에 빌드 ID 참가 권한을 부여합니다. 프로젝트 설정>리포지토리>(리포지토리)>권한으로 이동합니다. 최대 두 개의 ID가 있을 수 있습니다. 하나는 프로젝트 컬렉션 빌드 서비스용이고 다른 하나는 프로젝트 빌드 서비스용일 수 있습니다. 참가 권한이 허용으로 되어 있는지 확인하세요.

새 기본 분기에 분기 정책이 있는 경우, 푸시 작업을 수행할 때 빌드 식별자에게 정책 우회 권한도 부여합니다. 악의적인 사용자가 프로젝트의 리포지토리에 코드를 몰래 넣는 파이프라인을 만들 수 있기 때문에 이 권한은 보안 위험입니다. 미러링이 더 이상 필요하지 않은 경우 이 권한을 제거 해야 합니다 .
새 파일 mirror.yml을 기본 분기의 새 브랜치에 리포지토리에 추가하세요. 이 예제에서는 이전 기본 분기가 master 이고, 새 분기는 main입니다. 분기 이름이 다른 경우 트리거 분기 및 git push 줄을 업데이트합니다.

trigger:
  branches:
    include:
    - main
    - master
 
pool: { vmImage: ubuntu-latest }
steps:
- checkout: self
  persistCredentials: true
- script: |
    git checkout $(Build.SourceBranchName)
    git push origin HEAD:master HEAD:main
  displayName: Mirror old and new default branches

마법사에서 "Azure Repos Git" 및 "기존 Azure Pipelines YAML 파일"을 선택하여 새 파이프라인을 만듭니다. 이전 단계에서 추가한 mirror.yml 파일을 선택합니다. 파이프라인을 저장하고 실행합니다.

문제 해결

이 파이프라인은 master 또는 main로 푸시가 있을 때마다 실행됩니다. 새 커밋이 두 브랜치에 동시에 도착하지 않는 한 동기화됩니다.

"푸시된 분기 팁이 원격 분기보다 뒤에 있기 때문에 업데이트가 거부되었다는 오류 메시지가 나타나면서 파이프라인이 실패하기 시작하면, 누군가 이전 분기를 새 분기에 수동으로 병합해야 합니다."

리포지토리 및 cd 해당 디렉터리에 복제합니다.
기본 분기가 main인 경우, git checkout main로 새 기본 분기를 확인하세요.
새 브랜치 git checkout -b integrate를 만들어 두 브랜치를 통합합니다.
이전 기본 분기가 master인 경우 git merge master와 병합합니다.
새 브랜치를 푸시하고 나서 새로운 기본 브랜치로 풀 리퀘스트를 열어 완료합니다.
그런 다음 미러링 파이프라인은 병합 커밋을 이전 기본값으로 다시 미러링하는 작업을 처리해야 합니다.