Как сменить имя ветки по умолчанию в Git

Что такое ветка по умолчанию

Каждый новый репозиторий Git имеет ветку по умолчанию — это просто ссылка на коммит. Текущая ветка задаётся символической ссылкой HEAD. Исторически Git использовал имя “master” для этой ветки, но имя можно изменить.

Краткое определение: ветка по умолчанию — это ветка, на которую указывает HEAD сразу после создания репозитория и которую получают новые клоны по умолчанию.

Почему “master” постепенно уходит из практики

Терминология master/slave долго использовалась в технике, но у неё есть исторические коннотации, из-за которых сообщество выбирает более нейтральные имена. Кроме того, “master” не очень описательно — оно не объясняет роль ветки. Имя “main” чаще воспринимается как понятная и краткая альтернатива.

Git с версии 2.28 начал показывать подсказку при git init и позволяет настроить имя начальной ветки глобально.

Ветки, которые обычно выбирают вместо “master”: “main”, “trunk”, “development”.

Важно: смена имени ветки — изменение семантики проекта, требующее координации команды и обновления конфигураций CI/CD, защиты веток и ссылок в документации.

Как изменить имя ветки по умолчанию для новых репозиториев (глобально)

Чтобы задать имя ветки, используемой при создании новых репозиториев, выполните:

git config --global init.defaultBranch main

–global гарантирует, что настройка применяется для всех новых репозиториев текущего пользователя. После этого git init создаст ветку main вместо мастер.

Пример:

$ git init
Initialized empty Git repository in /path/to/repo/.git/
$ git status -sb
## No commits yet on main

Как переименовать ветку локально в любой момент

Вы можете переименовать текущую ветку командой:

git branch -m <новое-имя>

Например, чтобы поменять master на main:

# если вы находитесь на ветке master
git branch -m main

Если хотите переименовать не текущую ветку:

git branch -m old-name new-name

Пошаговая инструкция для существующих репозиториев (локально + удалённо)

Ниже — проверенная последовательность действий, минимизирующая простои и потерю истории.

1. Переименуйте локальную ветку:

# если текущая ветка — master
git branch -m main

2. Запушьте новую ветку и назначьте upstream:

git push -u origin main

3. На хостинге (GitHub/GitLab/Bitbucket) смените ветку по умолчанию в настройках репозитория на main.

4. После того как хостинг сменил ветку по умолчанию и CI начал собираться на новой ветке, удалите старую ветку с удалённого:

git push origin --delete master

5. Обновите локальные клоны коллег: каждая локальная копия, содержащая старую ссылку на master, должна выполнить:

# получить новую информацию об удалённом
git fetch origin
# поменять локальную ссылку, если нужно
git branch -m master main
# обновить upstream, если branch существовала
git branch --unset-upstream
git branch -u origin/main main
# удалить устаревшую ссылку на удалённую ветку
git remote prune origin

6. Обновите конфигурации: CI/CD скрипты, файлы настроек (например, GitHub Actions, .travis.yml), документацию, скрипты деплоя и любые ссылки на master.

Важно: не удаляйте старую ветку на удалённом, пока все интеграции и люди не переключились — лучше подождать несколько дней.

Как сменить ветку по умолчанию в GitHub

На GitHub ветки теперь по умолчанию создаются как main, но в существующих репозиториях вы можете изменить это вручную:

1. Откройте Settings в правом верхнем меню профиля проекта.
2. В меню слева выберите Repositories или Branches (иногда путь: Code and automation → Branches).
3. В разделе Repository default branch выберите желаемое имя ветки.
4. Нажмите Update.

После смены ветки по умолчанию GitHub автоматически обновит некоторые ссылки, но всё равно проверьте: защиту веток, интеграции и open PR.

Что нужно помнить перед массовой сменой имени ветки — контрольный список

Important: заранее проинформируйте команду и проверьте интеграции.

• Уведомьте команду и назначьте окно времени.
• Обновите CI/CD конфигурации и тесты.
• Проверьте protection rules и разрешения для новой ветки.
• Подготовьте инструкцию для разработчиков (см. раздел “Рольные чек-листы”).
• Оставьте старую ветку на удалённом до тех пор, пока все не переключатся, если нужна плавная миграция.

Рольные чек-листы

Для удобства — короткие инструкции по ролям.

• Maintainer / Администратор репозитория:

  • Сделать резервную копию настроек и заметки о текущей конфигурации.
  • Переименовать ветку локально и запушить новую.
  • Сменить ветку по умолчанию на хостинге.
  • Обновить protection rules и deploy-скрипты.
  • Уведомить команду и установить крайний срок удаления старой ветки.

• Разработчик / Contributor:

  • git fetch origin
  • git branch -m master main (если есть локальная master)
  • git branch -u origin/main main
  • git remote prune origin
  • Обновить локальные скрипты и IDE-конфигурации, если нужно

• DevOps / Инженер CI:

  • Обновить задачи CI/CD, переменные окружения и триггеры.
  • Проверить и изменить пути в деплой-скриптах.
  • Запустить тестовый прогон на новой ветке.

Частые ошибки и когда не стоит переименовывать

• Не стоит переименовывать на горячую в больших проектах без плана: множество интеграций могут сломаться.
• Не переименовывайте, если у вас есть external systems, жёстко завязанные на имени ветки и без возможности быстро обновить их.
• Не удаляйте старую ветку сразу после переименования — дождитесь переключения всех пользователей и CI.

Ментальные модели и рекомендации

• Видение: представьте ветку по умолчанию как “точку входа” для клонов и CI. Имя должно быть интуитивным.
• Малые шаги: сначала смените имя для новых репозиториев (init.defaultBranch). Для больших репозиториев делайте миграцию поэтапно.
• Коммуникация: планируйте смену имени как небольшую операцию изменения инфраструктуры.

Мини-методология миграции (Playbook)

1. Оценка: собрать список зависимостей (CI, деплой, внешние интеграции).
2. Тестирование: выполнить миграцию в тестовом/копии репозитория.
3. Миграция: выполнить шаги переименования и запушить новую ветку.
4. Проверка: убедиться, что CI, PR и окружения работают.
5. Очистка: удалить старую ветку после полного переключения.
6. Документирование: обновить README и внутренние инструкции.

Примеры команд (cheat sheet)

# Сделать main веткой по умолчанию для новых репозиториев
git config --global init.defaultBranch main

# Переименовать текущую ветку master в main локально
git branch -m main

# Запушить новую ветку и назначить upstream
git push -u origin main

# Удалить старую ветку на удалённом после переключения
git push origin --delete master

Диаграмма решения (когда менять)

flowchart TD
  A[Новый репозиторий?] -->|да| B[Задать init.defaultBranch перед git init]
  A -->|нет| C[Существующий репозиторий]
  C --> D{Есть ли интеграции, зависящие от имени ветки?}
  D -->|да| E[План миграции + тестирование]
  D -->|нет| F[Можно переименовать локально и на хостинге]
  E --> G[Тестовый репозиторий]
  G --> H[Миграция в продакшн по шагам]

Критерии приёмки

• Новые клонирования получают main по умолчанию.
• CI/CD успешно запускается на новой ветке.
• Все разработчики обновили локальные ссылки и настроили upstream.
• Документация и скрипты обновлены.

Краткий глоссарий

• HEAD — текущая ссылка на ветку или коммит.
• init.defaultBranch — глобальная настройка Git, задающая имя начальной ветки.
• upstream — удалённая ветка, с которой локальная ветка синхронизируется.

Итоги

Сменить имя ветки по умолчанию в Git просто, но при массовой миграции важно спланировать действия и учесть зависимости. Для новых репозиториев рекомендуют установить init.defaultBranch, а для существующих — использовать пошаговую процедуру: переименование локально, пуш новой ветки, смена ветки по умолчанию на хостинге и удаление старой ветки после проверки.

Notes: сохраняйте осторожность при удалении старых веток и всегда уведомляйте команду заранее.