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 не е специален клон с особени свойства, а обикновена препратка към commit, която по конвенция се счита за основна. 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 клона

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

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

Конфигурирането на всички шест правила — стандарт за мобилни проекти с аудитория от 10 000+ потребители. За малки проекти първите три правила са достатъчни.

Сравнение на нивата на защита за различни типове проекти

Нивото на защита на main зависи от мащаба на проекта. Стартъп може да се справи с минимална защита, докато enterprise приложението изисква максимални ограничения.

Версии и етикети в main

Етикетиране (tagging) — практика за създаване на именувани препратки към конкретни commits в main. Всеки етикет съответства на версия на приложението, пусната в продукция. Това позволява бързо превключване към всяка предишна версия за дебъгване или кръпка.

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

Етикетът се създава след сливане на release клона в main. Този commit след това се изгражда в 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) гарантира създаването на commit за сливане, дори ако сливането би могло да се извърши чрез просто преместване на указателя. Това запазва информацията, че промените идват от 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

# Коригиране и commit
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