Main та Master Branch у Git: що це і навіщо потрібна основна гілка

Що таке Main / Master Branch у Git

Main Branch (або Master — залежно від налаштувань репозиторію) — це гілка за замовчуванням, яка створюється при ініціалізації будь-якого Git-репозиторію. Вона є основною гілкою проєкту та містить код, готовий до розгортання в продакшен.

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

Ключовий принцип: main завжди має бути стабільною. Якщо в main виявлено помилку, це означає терміновий hotfix, який потрібно випустити поза чергою. Тому в професійних проєктах main захищена від випадкових змін правилами захисту гілки.

За даними 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 автоматично запускає деплой у продакшен. Ця модель вимагає високої автоматизації тестування та дисципліни команди.

У GitHub Flow немає develop гілки. Всі feature гілки створюються прямо від main, а після завершення зливаються назад через Pull Request. Кожне злиття в main автоматично запускає деплой у продакшен. Ця модель вимагає високої автоматизації тестування та дисципліни команди.

Захист гілки main

Захист гілки для 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

Тегування — практика створення іменованих посилань на конкретні коміти в main. Кожен тег відповідає версії додатку, випущеній у продакшен. Це дозволяє швидко переключитися на будь-який попередній реліз для налагодження або патча.

Стандарт іменування тегів у мобільній розробці — SemVer (Семантичне Версіонування): 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