Изменение ветви по умолчанию

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-адресе.

Если URL-адрес содержит строку versionзапроса, например &version=GBmybranchname, этот URL-адрес следует обновить. К счастью, большинство ссылок на ветвь по умолчанию не version будет сегмента и может быть оставлен как есть. Кроме того, после удаления старой ветвь по умолчанию попытка перейти к ней будет доставлена в новое значение по умолчанию.

Временное зеркало

Репозиторий Git может содержать только одну ветвь по умолчанию. Однако в течение некоторого времени можно настроить нерегламентированные зеркало между старым значением по умолчанию и новым по умолчанию. Таким образом, если конечные пользователи продолжают отправлять старые значения по умолчанию, они не должны повторно выполнять работу в конце. Мы будем использовать Azure Pipelines для настройки этого временного зеркало.

Примечание.

В этом разделе используется язык, который не соответствует перспективам Майкрософт. В частности, слово master отображается в нескольких местах в соответствии с тем, как оно использовалось в Git. Цель этого раздела — объяснить, как перейти на более инклюзивное язык, например main. Избегая всех упоминание master будет сделать направления гораздо труднее понять.

Конвейер зеркало ing

Примечание.

Эти инструкции не являются обманутыми, и настройка репозитория может потребовать дополнительных изменений, таких как свободные разрешения и политики.

Предупреждение

Если старые и новые ветвь по умолчанию обновляются до выполнения этого конвейера, конвейер не сможет зеркало изменений. Кому-то придется вручную объединить старый ветвь по умолчанию в новый ветвь по умолчанию, чтобы он работал автоматически.

1. Для всех существующих сборок CI обновите их для активации новых ветвь по умолчанию вместо старого.

2. Предоставьте удостоверению сборки разрешение на участие в репозитории. Перейдите к разделу Project Параметры> Repositories>(your repo)>Permissions. Может быть до двух удостоверений, один для службы сборки коллекции проектов и другой для службы сборки проекта. Убедитесь, что разрешение "Участие" говорит "Разрешить".

3. Если в новой ветвь по умолчанию есть политики ветвей, также предоставьте удостоверение сборки политикам обхода при отправке разрешений. Это разрешение представляет собой риск безопасности, так как злоумышленник может создать конвейер для создания кода в репозиторий в проекте. Если зеркало больше не требуется, удалите это разрешение.

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" и "Существующий файл YAML Azure Pipelines" в мастере. Выберите файл, добавленный mirror.yml на предыдущем шаге. Сохраните и запустите конвейер.

Устранение неполадок

Этот конвейер будет выполняться каждый раз, когда выполняется отправка в master или в main. Он будет хранить их в синхронизации до тех пор, пока новые фиксации не поступают в обе ветви одновременно.

Если конвейер начинает сбой с сообщением об ошибке, например "Обновления были отклонены, так как толчок ветви находится за его удаленным", кто-то должен объединить старую ветвь в новую ветвь вручную.

1. Клонируйте репозиторий и cd в его каталог.
2. Ознакомьтесь с новыми ветвь по умолчанию git checkout main (если main это ваш новый ветвь по умолчанию).
3. Создайте новую ветвь для интеграции двух ветвей с git checkout -b integrate.
4. Слияние старых ветвь по умолчанию с git merge master (если master это ваш старый ветвь по умолчанию).
5. Отправьте новую ветвь, а затем откройте и завершите запрос на вытягивание в новую ветвь по умолчанию.
6. Затем конвейер зеркало ing должен заботиться о зеркало фиксации слияния обратно в старое значение по умолчанию.