Main и Master Branch в Git: что это, зачем нужна основная ветка

Что такое Main / Master Branch в Git

Main Branch (или Master — в зависимости от настроек репозитория) — это ветка по умолчанию, которая создаётся при инициализации любого Git-репозитория. Она является основной веткой проекта и содержит код, готовый к развёртыванию в продакшн.

В отличие от develop, где кипит ежедневная работа с новыми функциями, main — это витрина проекта. Каждая версия кода в main прошла полный цикл: разработка в feature ветке, интеграция в develop, подготовка релиза в release ветке и финальное тестирование. Только после этого изменения попадают в main.

Ключевой принцип: main всегда должна быть стабильной. Если в main обнаружена ошибка, это означает срочный hotfix, который нужно выпустить вне очереди. Поэтому в профессиональных проектах main защищена от случайных изменений branch protection rules.

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

Переход с master на main

Исторически ветка по умолчанию в Git называлась master. В июне 2020 года Black Lives Matter движение привлекло внимание к терминам master и slave в IT-индустрии. GitHub объявил о переходе на термин main для ветки по умолчанию.

С октября 2020 года все новые репозитории на GitHub создаются с веткой main. GitLab и Bitbucket также внедрили поддержку main как имени по умолчанию. Git 2.28 (июль 2020) добавил опцию init.defaultBranch для настройки имени ветки по умолчанию.

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

Для переименования ветки в существующем репозитории выполните:

# Локальное переименование master в main
git branch -m master main

# Обновление удалённого репозитория
git push -u origin main

# Удаление старой master на сервере
git push origin --delete master

# Обновление HEAD на сервере
# (через веб-интерфейс GitHub: Settings → Branches → Default branch)

Роль main в Git Flow и GitHub Flow

Git Flow и GitHub Flow по-разному определяют роль main-ветки. Выбор модели зависит от размера команды, частоты релизов и требований к стабильности кода.

Для мобильной разработки стандартом является Git Flow, так как публикация приложения в App Store и Google Play имеет фиксированные релизные циклы. GitHub Flow больше подходит для веб-проектов с возможностью деплоя несколько раз в день.

GitHub Flow — упрощённый подход

В GitHub Flow нет develop ветки. Все feature ветки создаются прямо от main, а после завершения сливаются обратно через Pull Request. Каждое слияние в main автоматически запускает деплой в продакшн. Эта модель требует высокой автоматизации тестирования и discipline команды.

В GitHub Flow нет develop ветки. Все feature ветки создаются прямо от main, а после завершения сливаются обратно через Pull Request. Каждое слияние в main автоматически запускает деплой в продакшн. Эта модель требует высокой автоматизации тестирования и discipline команды.

Защита main branch

Branch protection для main — обязательная настройка в любом коммерческом проекте. Без неё случайный push может отправить в продакшн незаконченный код или сломать работающее приложение для всех пользователей.

• Require pull request — прямой push в main запрещён. Все изменения через PR с ревью.
• Require approvals — минимум 2 approve для слияния в main (на случай ошибки одного ревьюера).
• Require status checks — все CI/CD проверки должны быть успешными перед слиянием.
• Require up-to-date — PR должен быть основан на последнем коммите main.
• Include administrators — защита действует даже на владельцев репозитория.
• Require signed commits — все коммиты в main должны быть подписаны GPG-ключом.

Настройка всех шести правил — стандарт для мобильных проектов с аудиторией от 10 000+ пользователей. Для небольших проектов достаточно первых трёх правил.

Сравнение уровней защиты для разных типов проектов

Уровень защиты main зависит от масштаба проекта. Стартап может обойтись минимальной защитой, а enterprise-приложение требует максимальных ограничений.

Релизы и теги в main

Тегирование (tagging) — практика создания именованных ссылок на конкретные коммиты в main. Каждый тег соответствует версии приложения, выпущенной в продакшн. Это позволяет быстро переключиться на любой предыдущий релиз для отладки или патча.

Стандарт именования тегов в мобильной разработке — SemVer (Semantic Versioning): v1.2.3, где первый номер — мажорная версия (breaking changes), второй — минорная (новые функции), третий — патч (исправления).

Тег создаётся после слияния release ветки в main. Этот коммит затем собирается в CI/CD, подписывается и отправляется в магазин приложений. Если в теге обнаружена ошибка, создаётся hotfix ветка от этого тега.

# Создание аннотированного тега релиза
git tag -a v2.4.1 -m "Release version 2.4.1"

# Отправка тега на сервер
git push origin v2.4.1

# Просмотр всех тегов в репозитории
git tag -l "v2.*"

# Создание hotfix ветки от конкретного тега
git checkout -b hotfix/crash-fix v2.4.1

Иерархия веток Git Flow

Понимание иерархии веток в Git Flow — основа для правильной организации совместной разработки. Каждый тип ветки имеет свой источник, назначение и правила слияния.

• Main (1-й уровень) — корневая ветка, содержит только релизные версии. Создаётся при инициализации репозитория.
• Develop (2-й уровень) — создаётся от main при старте проекта. Содержит интеграционный код всех функций.
• Feature (3-й уровень) — создаются от develop. Изолированная разработка отдельных функций.
• Release (2-й уровень) — создаётся от develop. Подготовка конкретного релиза к выпуску.
• Hotfix (2-й уровень) — создаётся от main. Срочное исправление критических ошибок продакшена.

Важное правило: feature никогда не сливается напрямую в main. feature → develop → release → main — правильная цепочка слияний. Нарушение этого правила лишает смысла всю модель Git Flow.

Примеры команд для работы с main

Рассмотрим сценарий: команда завершила подготовку релиза v2.5.0. Release ветка проверена и готова к слиянию в main. После слияния создаётся тег и релиз публикуется.

# Переключение на main и обновление
git checkout main
git pull origin main

# Слияние проверенной release ветки
git merge --no-ff release/2.5.0

# Создание тега релиза
git tag -a v2.5.0 -m "Release 2.5.0 - Payment integration"

# Отправка main и тега на сервер
git push origin main --tags

Флаг --no-ff (no fast-forward) гарантирует создание коммита слияния, даже если слияние можно было бы выполнить простым перемещением указателя. Это сохраняет информацию о том, что изменения пришли из release ветки, что упрощает анализ истории.

Работа с hotfix через main

Если в продакшене обнаружена критическая ошибка, процесс отличается от обычного релиза. Hotfix создаётся от main, а после исправления сливается как в main, так и в develop.

Если в продакшене обнаружена критическая ошибка, процесс отличается от обычного релиза. Hotfix создаётся от main, а после исправления сливается как в main, так и в develop.

# Создание hotfix ветки от main
git checkout main
git checkout -b hotfix/2.5.1-crash-fix

# Исправление и коммит
git add src/fix/
git commit -m "Fix crash on login screen"

# Слияние hotfix обратно в main
git checkout main
git merge --no-ff hotfix/2.5.1-crash-fix
git tag -a v2.5.1 -m "Hotfix 2.5.1"
git push origin main --tags

# Слияние hotfix также в develop
git checkout develop
git merge --no-ff hotfix/2.5.1-crash-fix
git push origin develop

# Удаление hotfix ветки
git branch -d hotfix/2.5.1-crash-fix