Zmienianie gałęzi domyślnej

Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019

Gałąź domyślna to pierwsza gałąź, którą usługa Git wyewidencjonuje na nowym klonie. Ponadto żądania ściągnięcia są domyślnie kierowane do tej gałęzi.

Omówimy proces zmiany gałęzi domyślnej. Omówimy również inne kwestie, które należy wziąć pod uwagę i zaktualizować podczas wprowadzania tej zmiany. Na koniec przyjrzymy się narzędziu do złagodzenia przejścia.

Ustawianie nowej gałęzi domyślnej

Możesz użyć gałęzi innej niż main w przypadku nowych zmian lub zmienić główny wiersz programowania w repozytorium. Aby zmienić domyślną nazwę gałęzi dla nowych repozytoriów, zobacz Wszystkie ustawienia i zasady repozytoriów.

Aby zmienić domyślną gałąź repozytorium na potrzeby scalania nowych żądań ściągnięcia, potrzebujesz co najmniej dwóch gałęzi. Jeśli istnieje tylko jedna gałąź, jest już domyślna. Aby zmienić wartość domyślną, musisz utworzyć drugą gałąź.

Uwaga

Zmiana gałęzi domyślnej wymaga uprawnień do edycji zasad . Aby uzyskać więcej informacji, zobacz Ustawianie uprawnień repozytorium Git.

1. W repozytorium projektu wybierz pozycję Gałęzie.

2. Na stronie Gałęzie wybierz pozycję Więcej opcji obok nowej gałęzi domyślnej, a następnie wybierz pozycję Ustaw jako gałąź domyślną.

   

3. Po ustawieniu nowej gałęzi domyślnej możesz usunąć poprzednią wartość domyślną, jeśli chcesz.

Przed wprowadzeniem tej zmiany należy wziąć pod uwagę inne aspekty.

Wybierz nazwę

Usługa Git 2.28 dodała możliwość wybierania początkowej nazwy gałęzi. Jednocześnie usługa Azure Repos, GitHub i inni dostawcy hostingu Git dodali możliwość wyboru innej początkowej nazwy gałęzi. Wcześniej gałąź domyślna miała prawie zawsze nazwę master. Najpopularniejszą alternatywną nazwą jest main. Mniej typowe opcje to i trunk development. Brak ograniczeń dotyczących używanych narzędzi lub zespołu, które są używane, każda prawidłowa nazwa gałęzi będzie działać.

Aktualizowanie innych systemów

Zmiana na inną gałąź domyślną może mieć wpływ na inne części przepływu pracy. Podczas planowania zmiany należy wziąć pod uwagę te części.

Pipelines

Zaktualizuj wyzwalacze ciągłej integracji dla wszystkich potoków. Projektant potoki można edytować w Internecie. Potoki YAML można edytować w odpowiednich repozytoriach.

Żądania ściągnięcia w locie

Utwórz ponownie każde otwarte żądanie ściągnięcia do nowej gałęzi domyślnej.

Istniejące klony

Nowe klony repozytorium otrzymają nową gałąź domyślną. Po przełączeniu wszyscy z istniejącym klonem powinni uruchomić git remote set-head origin -a (zastępując origin ją nazwą zdalną, jeśli jest to coś innego), aby zaktualizować widok gałęzi domyślnej zdalnego. Przyszłe nowe gałęzie powinny być oparte na nowej wartości domyślnej.

Łącza przychodzące

Niektóre zakładki, dokumenty i inne pliki inne niż kod, które wskazują pliki w usłudze Azure Repos, muszą zostać zaktualizowane. Nazwa gałęzi pliku lub katalogu może być wyświetlana w adresie URL.

Jeśli adres URL zawiera ciąg zapytania dla versionelementu , na przykład &version=GBmybranchname, adres URL powinien zostać zaktualizowany. Na szczęście większość linków do gałęzi domyślnej nie będzie miała segmentu version i może być pozostawiona w takiej postaci. Ponadto po usunięciu starej gałęzi domyślnej próby przejścia do niej zostaną mimo to przełączony do nowej domyślnej gałęzi.

Dublowanie tymczasowe

Repozytorium Git może mieć tylko jedną gałąź domyślną. Jednak na chwilę można skonfigurować dublowanie ad hoc między starą wartością domyślną a nową wartością domyślną. W ten sposób, jeśli użytkownicy końcowi będą nadal wypychać do starej wartości domyślnej, nie będą musieli ponownie wykonywać pracy na ich końcu. Użyjemy usługi Azure Pipelines do skonfigurowania tego tymczasowego dublowania.

Uwaga

W tej sekcji używany jest język, który jest sprzeczny z perspektywą firmy Microsoft. W szczególności słowo master pojawia się w kilku miejscach spójnych ze sposobem jego użycia w usłudze Git. Celem tego tematu jest wyjaśnienie, jak przełączyć się na bardziej inkluzywny język, na przykład main. Unikanie wszystkich wspomnień master sprawi, że wskazówki będą znacznie trudniejsze do zrozumienia.

Potok dublowania

Uwaga

Te instrukcje nie są niezawodne, a konfiguracja repozytorium może wymagać dodatkowych zmian, takich jak poluzowanie uprawnień i zasad.

Ostrzeżenie

Jeśli stare i nowe gałęzie domyślne zostaną zaktualizowane przed uruchomieniem tego potoku, potok nie będzie mógł dublować zmian. Ktoś będzie musiał ręcznie scalić starą gałąź domyślną z nową gałęzią domyślną, aby ponownie ją uruchomić.

1. W przypadku wszystkich istniejących kompilacji ciągłej integracji zaktualizuj je tak, aby były wyzwalane względem nowej gałęzi domyślnej zamiast starej.

2. Przyznaj tożsamości kompilacji uprawnienie Współtworzenie do repozytorium. Przejdź do pozycji Project Ustawienia> Repositories>(twoje repozytorium)>Uprawnienia. Może istnieć do dwóch tożsamości— jedna dla usługi kompilacji kolekcji projektów, a druga dla usługi kompilacji projektu. Upewnij się, że uprawnienie Współtworzenie ma napis Zezwalaj.

3. Jeśli nowa gałąź domyślna ma zasady gałęzi, przyznaj również tożsamość kompilacji zasady Obejścia podczas wypychania uprawnień. To uprawnienie jest zagrożeniem bezpieczeństwa, ponieważ złośliwy użytkownik może utworzyć potok, aby wkraść kod do repozytorium w projekcie. Jeśli dublowanie nie jest już potrzebne, pamiętaj, aby usunąć to uprawnienie.

4. Dodaj nowy plik mirror.yml do repozytorium w nowej gałęzi domyślnej. W tym przykładzie przyjęto założenie, że stara gałąź domyślna to master , a nowa gałąź to main. Zaktualizuj gałęzie wyzwalające i wiersz, git push jeśli nazwy gałęzi są inne.

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. Utwórz nowy potok, wybierając pozycję "Azure Repos Git" i "Istniejący plik YAML usługi Azure Pipelines" w kreatorze. mirror.yml Wybierz plik dodany w poprzednim kroku. Zapisz i uruchom potok.

Rozwiązywanie problemów

Ten potok będzie uruchamiany za każdym razem, gdy jest wykonywane wypychanie do master elementu lub do main. Zachowa to synchronizację tak długo, jak nowe zatwierdzenia nie są dostarczane jednocześnie w obu gałęziach.

Jeśli potok rozpoczyna się niepowodzeniem z komunikatem o błędzie, na przykład "Aktualizacje zostały odrzucone, ponieważ wypchnięta porada gałęzi znajduje się za jej zdalnym", ktoś będzie musiał scalić starą gałąź z nową gałęzią ręcznie.

1. Sklonuj repozytorium i cd do jego katalogu.
2. Wyewidencjonuj nową gałąź domyślną git checkout main za pomocą polecenia (jeśli main jest to nowa gałąź domyślna).
3. Utwórz nową gałąź na potrzeby integracji dwóch gałęzi z elementem git checkout -b integrate.
4. Scal starą gałąź domyślną z gałęzią (jeśli master jest starą gałęzią git merge master domyślną).
5. Wypchnij nową gałąź, a następnie otwórz i ukończ żądanie ściągnięcia do nowej gałęzi domyślnej.
6. Potok dublowania powinien następnie uwzględniać dublowanie zatwierdzenia scalania z powrotem do starej wartości domyślnej.