Смена ветки по умолчанию в Git и GitHub

TL;DR

Если вы видите ветку master и хотите более понятное или инклюзивное имя, легко изменить имя ветки по умолчанию локально и на GitHub. Для новых репозиториев задайте глобальный параметр init.defaultBranch, а для уже существующих переименуйте локальную ветку, обновите удалённый репозиторий и проверьте CI, защиты веток и ссылки в документации.

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

Git долго использовал имя ветки по умолчанию master. Сегодня многие проекты переезжают на более описательные и инклюзивные имена, например main или trunk. В этой статье вы найдёте пошаговые команды, контрольный список миграции, рекомендации для ролей команды и альтернативные подходы.

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

В любом новом Git-репозитории есть ветка по умолчанию. Это просто ссылочный указатель на начальную серию коммитов. HEAD указывает на ветку, с которой вы работаете. Исторически это называлось master — но это только имя, а не техническая обязанность.

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

Почему master устаревает и какие есть альтернативы

Термин master пришёл из ранней компьютерной терминологии. Он вызывает опасения из-за ассоциаций с master/slave и при этом не информативен. Лучшие альтернативы:

• main — короткое, популярное и понятное имя.
• trunk — уместно в команде, которая использует модель trunk-based development.
• development или dev — если вы хотите явно отличать стабильную и рабочую ветки.

Выбор зависит от команды и рабочего процесса.

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

Чтобы все новые локальные репозитории, которые вы создаёте, начинались не с master, выполните одну команду:

# установит main как ветку по умолчанию для новых репозиториев текущего пользователя
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

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

# если вы сейчас на ветке master и хотите переименовать её в main
git branch -m main

Как перенести существующий репозиторий на GitHub с переименованием ветки

Ниже — распространённая последовательность шагов для безопасного переименования master → main в уже опубликованном репозитории.

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

git checkout master
git branch -m master main

2. Отправьте новую ветку и установите upstream:

git push -u origin main

3. На GitHub (в веб-интерфейсе) смените ветку по умолчанию на main (или используйте API):

• Перейдите в Settings → Branches → Default branch → выберите main → Update.

4. Удалите старую удалённую ветку master (опционально, после проверки):

git push origin --delete master

5. Обновите локальные клонирования коллег: они должны выполнить

git fetch origin
git branch -m master main        # переименовать локально, если нужно
git branch -u origin/main main   # установить upstream
git remote set-head origin -a    # обновить HEAD удалённого репозитория

6. Проверьте и обновите:

• конфигурацию CI/CD и скрипты деплоя;
• защищённые ветки (branch protection) в настройках репозитория;
• ссылки в документации, скриптах и подмодулях;
• настройки GitHub Pages и Actions.

Контрольный список перед и после переименования

Короткий playbook для безопасной миграции:

• Сообщите команде о дате и времени миграции.
• Создайте резервную копию репозитория (mirror clone) при больших рисках.
• Выполните переименование в тестовом репозитории.
• Переименуйте локально, отправьте новую ветку, смените default в GitHub.
• Обновите CI/CD, protection rules, webhooks и deploy keys.
• Убедитесь, что автоматические интеграции (issue trackers, bots) работают.
• Удалите старую ветку после подтверждения, что всё в порядке.

Рекомендации по ролям: кто за что отвечает

Maintainer

• планирует миграцию; сообщает команде; меняет default в GitHub; обновляет protection rules.

Разработчик

• обновляет локальные репозитории и ветки; проверяет, что PR открываются в новую ветку; обновляет локальные скрипты.

Инженер CI/CD

• проверяет пайплайны; обновляет конфиги, которые хардкодят имя ветки; тестирует деплой.

Документация

• обновляет README, CONTRIBUTING, ссылки в коде и автоматических скриптах.

Когда не стоит менять имя ветки

• Если проект мёртв и никто не поддерживает репозиторий, изменения принесут мало пользы.
• Если в инфраструктуре присутствуют старые системы, которые нельзя оперативно обновить, риск может превысить выгоду.

Альтернативные подходы

• Оставить master, но обозначить в CONTRIBUTING политику ветвления. Подходит для больших экосистем, где изменение создаст больше работы.
• Создать новую ветку main и перейти на неё постепенно: мерджить все изменения из master в main, не удаляя master пока не будет полной уверенности.

Подводные камни и как их избежать

• CI и деплой хардкодят ветку — заранее найдите и измените такие места.
• Submodule и URL с упоминанием ветки — обновите ссылки.
• Webhooks и интеграции — проверьте, что они ссылаются на новую ветку.
• Локальные рабочие деревья у коллег — оставьте инструкцию и команды для быстрого перехода.

Модель принятия решения: какую выбрать имя ветки

flowchart TD
  A[Нужна простая ветка для основной разработки?] -->|Да| B[Выберите main]
  A -->|Нет| C[Требуется trunk-based workflow?]
  C -->|Да| D[Выберите trunk]
  C -->|Нет| E[Хотите явно отделить dev от production?]
  E -->|Да| F[Выберите development или dev]
  E -->|Нет| G[Обсудите с командой]

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

• Все разработчики могут пушить и открывать PR в новую ветку.
• CI-пайплайны успешно запускаются на новой ветке.
• Деплой на staging/production не нарушен.
• Документация и скрипты обновлены.
• Старые ссылки на master либо обновлены, либо корректно перенаправляют.

Быстрая шпаргалка команд

• Установить глобально имя по умолчанию:

git config --global init.defaultBranch main

• Переименовать текущую локальную ветку в main:

git branch -m main

• Отправить новую ветку и установить upstream:

git push -u origin main

• Удалить старую удалённую ветку master:

git push origin --delete master

• Обновить локальный HEAD для удалённого репозитория:

git remote set-head origin -a

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

1. Назначьте владельца миграции.
2. Согласуйте окно миграции и уведомления для команды.
3. Сделайте dry-run в тестовом репозитории.
4. Выполните шаги переименования и смены default в рабочем репозитории.
5. Проверьте CI, deployment и интеграции.
6. Отправьте инструкцию по обновлению для всех разработчиков.
7. По истечении испытательного периода удалите старую ветку.

1‑строчная глоссарий

• default branch — ветка, выбранная по умолчанию для клонирования и PR.
• upstream — удалённая ветка, с которой связана локальная ветка.
• branch protection — правила защиты ветки на платформе.

Итоги

Переименование ветки по умолчанию в Git и GitHub — небольшая, но полезная операция. Она делает ваш проект понятнее и может улучшить инклюзивность. Переход требует планирования: убедитесь, что CI, деплой и документация обновлены, и заранее предупредите команду.

Ключевые шаги: задать init.defaultBranch для новых репозиториев, локально переименовать ветку, отправить новую ветку, сменить default на GitHub и проверить интеграции.

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

Краткая заметка: чтобы изучить Git дальше и перейти от базовых операций к продвинутым сценариям, ищите руководства по ветвлению, стратегиям слияния и безопасным практикам CI/CD.