기본 분기 변경

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

기본 분기 Git이 새 클론에서 검사 첫 번째 분기입니다. 또한 끌어오기 요청은 기본적으로 이 분기를 대상으로 합니다.

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

새 기본 분기 설정

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

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

참고 항목

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

1. 프로젝트 리포지토리에서 분기를 선택합니다.

2. 분기 페이지에서 원하는 새 기본 분기 옆에 있는 추가 옵션을 선택하고 기본 분기 집합을 선택합니다.

   

3. 새 기본 분기 설정한 후 원하는 경우 이전 기본값을 삭제할 수 있습니다.

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

이름 선택

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

다른 시스템 업데이트

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

Pipelines

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

기내 끌어오기 요청

열려 있는 각 끌어오기 요청을 새 기본 분기 대상을 다시 지정합니다.

기존 클론

리포지토리의 새 복제본은 새 기본 분기 가져옵니다. 전환 후 기존 클론을 가진 모든 사용자가 실행 git remote set-head origin -a (다른 경우 원격의 이름으로 대체origin)하여 원격의 기본 분기 보기를 업데이트해야 합니다. 이후의 새 분기는 새 기본값을 기반으로 해야 합니다.

들어오는 링크

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

예를 들어 &version=GBmybranchnameURL에 대한 version쿼리 문자열이 포함된 경우 해당 URL을 업데이트해야 합니다. 다행히 기본 분기 대한 대부분의 링크에는 세그먼트가 version 없으며 그대로 둘 수 있습니다. 또한 이전 기본 분기 삭제하면 이 기본 분기 탐색하려고 하면 새 기본값으로 이동됩니다.

임시 미러

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

참고 항목

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

미러 파이프라인

참고 항목

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

Warning

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

1. 모든 기존 CI 빌드의 경우 이전 빌드 대신 새 기본 분기 대해 트리거하도록 업데이트합니다.

2. 리포지토리에 빌드 ID 참가 권한을 부여합니다. Project 설정>리포지토리>(리포지토리)>권한으로 이동합니다. 최대 두 개의 ID가 있을 수 있습니다. 하나는 프로젝트 컬렉션 빌드 서비스용이고 다른 하나는 프로젝트 빌드 서비스용일 수 있습니다. 참가 권한에 허용이 표시 되어 있는지 확인합니다.

3. 새 기본 분기 분기 정책이 있는 경우 권한을 푸시할 때 빌드 ID에 바이패스 정책도 부여합니다. 악의적인 사용자가 프로젝트의 리포지토리에 코드를 몰래 넣는 파이프라인을 만들 수 있기 때문에 이 권한은 보안 위험입니다. 미러 더 이상 필요하지 않은 경우 이 권한을 제거해야 합니다.

4. 새 기본 분기 리포지토리에 새 파일을 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

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

문제 해결

이 파이프라인은 푸시 master main가 있을 때마다 실행됩니다. 새 커밋이 두 분기에 동시에 도착하지 않는 한 동기화 상태를 유지합니다.

"푸시된 분기 팁이 원격 뒤에 있기 때문에 업데이트 거부되었습니다."와 같은 오류 메시지로 파이프라인이 실패하기 시작하면 누군가가 이전 분기를 새 분기에 직접 병합해야 합니다.

1. 리포지토리 및 cd 해당 디렉터리에 복제합니다.
2. 새 기본 분기 git checkout main 있는 경우main)를 사용하여 새 기본 분기 확인합니다.
3. 두 분기를 .와 통합하기 위한 새 분기 git checkout -b integrate를 만듭니다.
4. 이전 기본 분기 git merge master 병합합니다(이전 기본 분기 경우master).
5. 새 분기를 푸시한 다음 끌어오기 요청을 열고 새 기본 분기 완료합니다.
6. 그런 다음 미러 파이프라인은 병합 커밋을 이전 기본값으로 다시 미러 처리해야 합니다.