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 аутоматски покреће постављање на производњу. Овај модел захтева високу аутоматизацију тестирања и дисциплину тима.

У 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 мора бити заснован на последњем комиту 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