Ветка по умолчанию в Git main и master

Введение

Ветка по умолчанию в Git – это основная линия разработки, к которой по умолчанию привязаны большинство операций: создание репозитория, открытие pull/merge‑запросов, просмотр кода в веб‑интерфейсе, деплой на продакшн и многое другое. Исторически такой веткой была master, но несколько лет назад экосистема перешла на имя main.

Сейчас вы можете встретить оба варианта: в старых проектах по-прежнему используется master, в новых чаще всего создается main. Важно понимать, как Git выбирает ветку по умолчанию, как ее переименовать, как не «сломать» удаленный репозиторий и CI/CD, и как настроить имя ветки по умолчанию для всех новых репозиториев.

В этой статье вы разберетесь:

• чем отличаются main и master с точки зрения Git;
• как узнать, какая ветка сейчас является основной;
• как переименовать ветку master в main (и наоборот);
• как настроить имя ветки по умолчанию для новых репозиториев;
• как учесть особенности GitHub, GitLab и других хостингов.

Я буду показывать команды и обязательно добавлять комментарии, чтобы вам было проще понять, что происходит на каждом шаге.

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

Локальный репозиторий и ветка HEAD

В самом Git нет «магической» ветки. Есть указатель HEAD, который ссылается на текущую ветку или конкретный коммит.

Когда вы создаете пустой локальный репозиторий:

git init
# Инициализируем новый Git-репозиторий в текущей папке

Git создает:

• пустой репозиторий;
• начальную ветку с именем, которое определяется конфигурацией (main или master);
• символическую ссылку HEAD, указывающую на эту ветку.

Посмотрите, куда указывает HEAD:

cat .git/HEAD
# Вывод показывает ссылку на ветку, например:
# ref: refs/heads/main
# или
# ref: refs/heads/master

Комментарий:

• файл .git/HEAD хранит ссылку на текущую ветку;
• имя ветки (main или master) задается настройкой init.defaultBranch.

То есть с точки зрения «чистого» Git ветка по умолчанию – это та, на которую указывает HEAD сразу после git init.

Удаленный репозиторий и default branch

Когда вы работаете с удаленным репозиторием (на GitHub, GitLab, Bitbucket и т.д.), возникает еще одно понятие – default branch на сервере.

Эта ветка:

• открывается по умолчанию в веб‑интерфейсе;
• используется как база для pull/merge‑запросов по умолчанию;
• часто является источником для продакшн‑деплоя и CI‑пайплайнов;
• используется некоторыми инструментами при клонировании (если сервер сообщает имя основной ветки).

Если вы выполните:

git clone https://github.com/user/project.git
# Клонируем репозиторий с GitHub

Git после клонирования:

• автоматически создает локальную ветку, соответствующую ветке по умолчанию на сервере;
• делает ее текущей;
• настраивает remote origin так, чтобы эта ветка отслеживала соответствующую ветку на сервере.

То есть локальная «ветка по умолчанию» после клонирования – это реплика default branch с сервера.

Как Git решает, какое имя использовать для начальной ветки

Сейчас Git использует следующую логику:

1. Сначала смотрит на конфигурацию init.defaultBranch (глобальную или системную).
2. Если она задана – создает ветку с этим именем.
3. Если не задана – использует значение по умолчанию, которое зависит от версии Git и настроек сборки (в современных версиях часто main, в старых – master).

Посмотреть текущее значение можно так:

git config --get init.defaultBranch
# Если команда ничего не выводит - значение не установлено явно

Мы еще вернемся к настройке этого параметра, когда будем говорить о конфигурации под main или master.

История перехода от master к main

Почему вообще появился main

Исторически в Git использовалась ветка master как основная. Однако сообщество и крупные хостинги (GitHub, GitLab, Bitbucket и др.) пришли к решению отказаться от слова master в качестве значения по умолчанию и перейти на main.

С технической точки зрения:

• main и master – это просто строки, имена веток;
• Git не привязывает к ним никакого специального поведения;
• все отличия – в настройках и привычках инструментов вокруг Git.

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

Как ведут себя популярные хостинги

Смотрите, кратко по платформам (на момент написания):

• GitHub – по умолчанию создает ветку main при создании нового репозитория в веб‑интерфейсе;
• GitLab – также по умолчанию использует main для новых проектов (хотя поведение можно настроить);
• Bitbucket – поддерживает main как рекомендованное имя, но можно выбрать другое при создании.

При этом старые репозитории с master продолжают работать как раньше. Переход обязателен только по вашему желанию.

Как узнать, какая ветка сейчас основная

Локальный репозиторий

Если вы хотите понять, какая ветка является текущей и фактически «основной» для этого клона, используйте:

git branch
# Звездочкой (*) будет помечена текущая ветка, например:
# * main
#   feature/login
#   hotfix/header

Комментарий:

• звездочка показывает, на какой ветке сейчас находится HEAD;
• именно эта ветка считается «основной» в рамках текущей сессии, но не обязательно является default branch на сервере.

Чтобы понять, какая ветка отслеживает удаленную основную ветку:

git remote show origin
# В выводе ищите строку:
#   HEAD branch: main
# или
#   HEAD branch: master

Комментарий:

• HEAD branch в этом выводе показывает ветку по умолчанию на удаленном репозитории;
• Git использует ее при клонировании и некоторых других операциях.

На GitHub

На GitHub default branch можно увидеть:

• на главной странице репозитория: выпадающий список веток обычно показывает основную ветку первой;
• в настройках репозитория: Settings → Branches → Default branch.

На GitLab

На GitLab:

• основная ветка подсвечена в списке веток;
• ее можно посмотреть и сменить в Settings → Repository → Default branch.

Настройка имени ветки по умолчанию для новых репозиториев

Частая задача – сделать так, чтобы при каждом git init создавалась ветка main, а не master (или наоборот, если вы поддерживаете старую инфраструктуру).

Настройка через init.defaultBranch

Покажу вам, как это сделать через глобальную конфигурацию:

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

Теперь, если вы создадите новый репозиторий:

mkdir my-new-project
cd my-new-project
git init
# Git создаст ветку main, а не master

Проверим:

git branch
# Вывод:
# * main

Если вам нужно вернуть master:

git config --global init.defaultBranch master
# Теперь новые репозитории будут начинаться с ветки master

Пояснение:

• флаг --global сохраняет настройку в файле ~/.gitconfig;
• настройка действует для всех новых репозиториев, созданных этой учетной записью;
• уже существующие репозитории не изменяются.

Системный и локальный уровни конфигурации

Настройку можно задать на разных уровнях:

• --system – для всей системы (влияет на всех пользователей, если у них нет своих переопределений);
• --global – для текущего пользователя;
• без флагов – только для конкретного репозитория.

Например, чтобы задать для конкретного репозитория:

git config init.defaultBranch main
# Теперь для этого репозитория при init (reinit) будет использоваться main

Чаще всего достаточно глобальной настройки.

Переименование master в main в локальном репозитории

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

Проверяем текущую ветку

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

git branch
# Допустим, вывод:
# * master
#   feature-x

Если вы не на master, переключитесь:

git checkout master
# Переключаемся на ветку master

Команда git branch -m

Теперь переименуем ветку:

git branch -m master main
# -m означает move - переименование или перенос ветки

Пояснение:

• git branch -m старое_имя новое_имя переименовывает локальную ветку;
• если вы находитесь на этой ветке – она продолжает быть текущей, но уже под новым именем.

Проверим:

git branch
# Вывод:
# * main
#   feature-x

Здесь вы видите, что master исчезла, а на ее месте появилась main.

Что произойдет с историей и коммитами

Важно понимать: при переименовании:

• история коммитов не меняется;
• хеши коммитов не пересчитываются;
• меняется только имя ссылки, которая указывает на последний коммит в этой ветке.

То есть переименование – это чисто «метаданные» на уровне имен веток.

Переименование ветки по умолчанию с учетом удаленного репозитория

На практике почти всегда есть удаленный репозиторий (origin). Давайте разберем полный сценарий миграции с master на main в проекте, который уже пушится на сервер.

Типовой сценарий миграции master → main

Я покажу вам стандартную последовательность действий, которая работает для GitHub, GitLab и большинства других хостингов.

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

Как и раньше:

git checkout master
# Переключаемся на ветку master

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

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

Теперь нам нужно опубликовать ветку main в удаленном репозитории и связать ее с origin:

git push -u origin main
# -u (или --set-upstream) связывает локальную ветку main с origin/main

Комментарий:

• эта команда создает ветку main на сервере;
• теперь локальная main будет отслеживать origin/main;
• но default branch на сервере пока, скорее всего, осталась master.

Шаг 3. Сменить ветку по умолчанию в веб‑интерфейсе

Теперь нужно изменить default branch на стороне хостинга.

На GitHub:

1. Откройте репозиторий.
2. Перейдите в Settings → Branches.
3. В разделе Default branch выберите main вместо master.
4. Подтвердите изменение.

На GitLab:

1. Откройте Project → Settings → Repository.
2. Найдите Default branch.
3. Выберите main и сохраните.

Этот шаг важен: только после него все новые pull/merge‑запросы и веб‑страницы будут использовать main как основную ветку.

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

Когда вы убедитесь, что все работает, можно удалить удаленную ветку master, чтобы не путать разработчиков:

git push origin --delete master
# Удаляем ветку master на удаленном репозитории

Комментарий:

• это не затрагивает локальные ветки других разработчиков;
• удаление ветки на сервере может нарушить старые CI‑конфигурации, если они явно ссылались на master, поэтому сначала проверьте пайплайны.

Шаг 5. Обновить локальные копии у других разработчиков

Разработчики, у которых есть клон репозитория, увидят ошибку при следующем пуше в master или просто не найдут ветку origin/master.

Им нужно:

git fetch origin
# Обновляем список удаленных веток

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

git branch -u origin/main main
# Настраиваем отслеживание origin/main

git remote set-head origin -a
# Обновляем локальную информацию о ветке по умолчанию на сервере

Пояснение по командам:

• git fetch origin подтягивает новую ветку main и информацию об удаленной master;
• git branch -m master main переименовывает локальную ветку;
• git branch -u origin/main main связывает локальную main с origin/main;
• git remote set-head origin -a говорит Git автоматически определить, какая ветка является HEAD (веткой по умолчанию) на сервере, и сохранить эту информацию локально.

Обратный сценарий main → master

Иногда вам, наоборот, нужно привести репозиторий к имени master (например, из-за старых скриптов). Шаги абсолютно симметричны:

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

   git checkout main
   git branch -m main master
   

2. Отправить master на сервер:

   git push -u origin master
   

3. Через веб‑интерфейс сменить default branch на master.

4. Удалить main на сервере (по необходимости):

   git push origin --delete main
   

5. Дать коллегам инструкцию по обновлению локальных репозиториев (аналогично, только с main → master).

Особенности клонирования репозиториев с разными default branch

Как Git выбирает ветку после git clone

Когда вы делаете:

git clone https://example.com/repo.git
# Клонируем репозиторий с сервера

Git:

• спрашивает у сервера, какая ветка является HEAD (веткой по умолчанию);
• создает у себя локальную ветку с этим именем;
• делает ее текущей;
• настраивает отслеживание (upstream) от локальной ветки к удаленной.

Посмотреть, что выбрал Git, можно так:

cd repo
git branch
# Вы увидите, на какую ветку вы попали - main или master

Чтобы явно увидеть ветку по умолчанию на origin:

git remote show origin
# В выводе ищите HEAD branch

Что, если сервер настроен неправильно

Иногда бывает, что:

• на сервере в настройках default branch указана master;
• при этом фактически разработка ведется в main.

В этом случае:

• при git clone вы попадете на master;
• можете не увидеть актуальный код;
• pull‑запросы и CI могут вести себя непредсказуемо.

Решение – корректно настроить default branch на сервере (через интерфейс платформы) и затем обновить локальную информацию:

git remote set-head origin -a
# Автоматически подтягиваем актуальную ветку HEAD с сервера

Ветка по умолчанию и CI/CD

Связь default branch и пайплайнов

Во многих проектах ветка по умолчанию – это именно та ветка, с которой:

• собирается продакшн‑релиз;
• запускаются основные CI‑проверки;
• деплоится приложение.

Конфигурационные файлы CI/CD (например, GitHub Actions, GitLab CI, Jenkins pipelines) часто явно ссылаются на имя ветки:

• .github/workflows/*.yml
• .gitlab-ci.yml
• Jenkinsfile
• другие конфигурации.

Например, в GitHub Actions вы можете увидеть:

on:
  push:
    branches:
      - master  # Запускать workflow только для ветки master

После перехода на main такая конфигурация перестанет запускаться при пуше в main. Нужно заменить:

on:
  push:
    branches:
      - main   # Теперь workflow запускается для ветки main

То же самое касается:

• правил protected branches;
• настроек auto-deploy;
• branch‑фильтров в различных хуках и интеграциях.

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

Когда вы меняете имя основной ветки (master → main или наоборот), проверьте:

1. Конфигурации CI (GitHub Actions, GitLab CI, CircleCI, Jenkins и т.д.).
2. Сценарии деплоя (bash‑скрипты, Ansible, Terraform), где может фигурировать имя ветки.
3. Документацию и README, где может быть указано имя основной ветки.
4. Настройки protected branches (например, защита от прямых пушей в main/master).
5. Webhooks и интеграции (Slack, Jira), если они фильтруют события по имени ветки.

Практические рекомендации: main или master

Когда использовать main

Рекомендуется использовать main, если:

• вы создаете новый репозиторий с нуля;
• вы работаете с открытым исходным кодом на GitHub или GitLab;
• в вашей компании принята политика использования main;
• вы хотите единообразия с экосистемой современных инструментов.

В этом случае просто:

1. Настройте глобально:

   git config --global init.defaultBranch main
   

2. При создании репозиториев на хостинге не меняйте значение по умолчанию (main).

Когда оставить master

Сохранение master может быть оправдано, если:

• у вас большая монолитная кодовая база со старыми скриптами и интеграциями;
• слишком много инструментов и конфигураций завязано на имя master;
• переименование может сломать критический продакшн‑пайплайн.

В таком случае можно:

• оставить master как основную ветку;
• постепенно готовить инфраструктуру к возможной миграции (обновлять конфиги, скрипты, документацию);
• явно зафиксировать в командных соглашениях, что master – основная ветка.

Важность единообразия в команде

С точки зрения Git все равно, как вы назовете ветку. Главное – чтобы команда:

• понимала, какая ветка основная;
• одинаково называла ее во всех документах и инструментах;
• не путала main и master в одном и том же проекте.

Хорошая практика – описать это в CONTRIBUTING.md или README, чтобы новые участники сразу понимали, куда отправлять изменения и от какой ветки ветвиться.

Дополнительные команды и полезные приемы

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

Если вам часто нужно проверять default branch remote‑репозитория, можно использовать:

git remote show origin | grep "HEAD branch"
# Фильтруем строку, где указана ветка по умолчанию

Вывод будет примерно таким:

  HEAD branch: main

Отслеживание ветки по умолчанию при переключении remotes

Иногда вы меняете remote origin (например, переходите с GitHub на GitLab). После смены origin стоит обновить локальный HEAD:

git remote set-url origin git@gitlab.com:group/project.git
# Меняем URL удаленного репозитория

git remote set-head origin -a
# Обновляем информацию о ветке по умолчанию из нового origin

Создание рабочей ветки от основной ветки

Частый паттерн: вы хотите создать новую ветку от основной (main или master), но не уверены, какая именно используется в конкретном проекте.

Можно сделать так:

git fetch origin
# Обновляем данные по origin

git remote show origin | grep "HEAD branch"
# Смотрим, какая ветка по умолчанию, допустим main

git checkout main
# Переключаемся на основную ветку

git pull
# Подтягиваем последние изменения

git checkout -b feature/some-task
# Создаем новую ветку от актуальной основной ветки

Так вы всегда исходите именно от актуальной default branch.

---

Заключение

Ветка по умолчанию в Git – это не особая «системная» сущность, а просто ветка, на которую ссылается HEAD в локальном репозитории и которую сервер помечает как default branch. Имя этой ветки может быть любым, но исторически сложились два самых распространенных варианта – master и main.

С точки зрения Git между ними нет принципиальной разницы: различия появляются только в инструментах вокруг (GitHub, GitLab, CI/CD, скрипты и документация). Поэтому при работе с веткой по умолчанию важно:

• понимать, какое имя используется в конкретном проекте;
• уметь настраивать init.defaultBranch для новых репозиториев;
• аккуратно выполнять миграцию master → main (или наоборот) с учетом удаленного репозитория и CI;
• следить за единообразием настроек и имен веток в команде.

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

---

Частозадаваемые технические вопросы по теме и ответы

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

Если вы хотите только для одного репозитория задать имя начальной ветки, сделайте так:

mkdir my-repo
cd my-repo

git init --initial-branch=develop
# Создаем репозиторий сразу с веткой develop вместо main/master

Комментарий:

• флаг --initial-branch (или коротко -b) определяет имя первой ветки;
• глобальную настройку init.defaultBranch менять не нужно.

---

Вопрос 2. Как узнать, есть ли в репозитории и main и master одновременно и какая из них сейчас основная на сервере

Сначала посмотрите список локальных веток и удаленных:

git branch
git branch -r
# В выводе смотрите наличие origin/main и origin/master

Затем:

git remote show origin | grep "HEAD branch"
# Определяете, какая ветка по умолчанию на сервере - main или master

Если есть обе ветки, а default branch включает, скажем, main, имеет смысл:

• перевести разработку только на main;
• удалить master с сервера и локально, когда убедитесь, что она не используется.

---

Вопрос 3. Что делать, если я случайно удалил локальную ветку main или master

Если удалена только локальная ветка, а на сервере все в порядке:

git fetch origin
# Обновляем информацию о ветках

git checkout -b main origin/main
# Восстанавливаем локальную ветку main из удаленной origin/main

Аналогично для master:

git checkout -b master origin/master

Комментарий:

• используем удаленную ветку как источник для восстановления локальной.

---

Вопрос 4. Как временно переключить default branch на другую ветку без переименования main/master

На сервере можно сменить default branch в настройках (например, на release/x.y), но локально вы можете просто:

git checkout release/x.y
# Делаем эту ветку текущей для работы

git push -u origin release/x.y
# Если нужно, чтобы сервер ее отслеживал

При этом:

• имя основной ветки main/master не меняется;
• вы просто используете другую ветку как «главную» для данного цикла разработки.

---

Вопрос 5. Почему после смены default branch на сервере у меня при git pull происходит мердж с неожиданной веткой

Скорее всего:

• локальная ветка (например, master) все еще отслеживает origin/master;
• при этом default branch на сервере уже main.

Решение:

1. Переключиться на основную ветку:

   git checkout main
   

2. Настроить отслеживание:

   git branch -u origin/main main
   

3. Убедиться, что git pull теперь тянет изменения именно из origin/main.

Если вы больше не используете master, можно удалить локальную ветку:

git branch -d master