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

Сервисы Azure DevOps | Azure DevOps Server | Azure DevOps Server 2022

Ветвь по умолчанию — это первая ветвь, которую Git будет проверять на свежем клоне. Кроме того, запросы на вытягивание по умолчанию нацелены на эту ветвь.

Мы рассмотрим процесс изменения ветви по умолчанию. Мы также рассмотрим другие аспекты, которые необходимо учитывать и обновлять при внесении этого изменения. Наконец, мы рассмотрим инструмент для облегчения перехода.

Предпосылки

Установка новой ветви по умолчанию

Вы можете использовать ветвь, кроме main для новых изменений или изменения основной линии разработки в репозитории. Чтобы изменить название ветки по умолчанию для новых репозиториев, см. параметры и политики всех репозиториев.

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

Перед внесением этого изменения следует рассмотреть другие аспекты.

Выбор имени

Git 2.28 добавлена возможность выбора начального имени ветви. В то же время Azure Repos, GitHub и другие поставщики услуг размещения Git добавили возможность выбора другого начального имени ветви. Ранее ветвь по умолчанию почти всегда называлась master. Наиболее популярным альтернативным именем является main. Менее распространенные варианты включают trunk и development. Если нет ограничений со стороны используемых инструментов или команды, любые допустимые названия веток будут работать.

Обновление других систем

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

Трубопроводы

Обновите триггеры CI для всех конвейеров. Конвейеры конструктора можно редактировать в Интернете. Конвейеры YAML можно редактировать в соответствующих репозиториях.

Запросы на вытягивание в полете

Перенаправьте каждый открытый пул-реквест на новую ветвь по умолчанию.

Существующие клоны

Новые клоны репозитория получат новую ветвь по умолчанию. После переключения все пользователи с существующим клоном должны запустить git remote set-head origin -a (заменяя origin названием удаленного репозитория, если это другое название), чтобы обновить отображение ветви по умолчанию в удаленном репозитории. Будущие новые ветви должны основываться на новом по умолчанию.

Входящие ссылки

Необходимо обновить некоторые закладки, документы и другие файлы, отличные от кода, которые указывают на файлы в Azure Repos. Имя ветви для файла или каталога может отображаться в URL-адресе.

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

Временное зеркальное отображение

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

Конвейер зеркального отображения

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

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

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. Отправьте новую ветку, а затем откройте и завершите pull request в новую ветку по умолчанию.
6. Затем конвейер зеркального отображения должен заботиться о зеркальной фиксации слияния обратно в старое значение по умолчанию.