Main at Master Branch sa Git: ano ito at bakit kailangan ang pangunahing branch

Ano ang Main / Master Branch sa Git

Main Branch (o Master — depende sa mga setting ng repositoryo) — ay ang default branch na nalilikha kapag nag-i-initialize ng anumang Git repositoryo. Ito ang pangunahing branch ng proyekto at naglalaman ng code na handa nang i-deploy sa produksyon.

Hindi tulad ng develop, kung saan nagaganap ang araw-araw na trabaho sa mga bagong feature, ang main ay ang display window ng proyekto. Bawat bersyon ng code sa main ay dumaan sa buong siklo: pag-develop sa feature branch, integrasyon sa develop, paghahanda ng release sa release branch, at pinal na pagsubok. Pagkatapos lamang nito pumapasok ang mga pagbabago sa main.

Pangunahing Prinsipyo: ang main ay dapat laging stable. Kung may matuklasang error sa main, nangangahulugan ito ng agarang hotfix na dapat ilabas nang wala sa schedule. Kaya naman sa mga propesyonal na proyekto, ang main ay protektado laban sa aksidenteng pagbabago sa pamamagitan ng branch protection rules.

Ayon sa Git Book, ang main ay hindi espesyal na branch na may natatanging katangian, kundi isang ordinaryong reference sa isang commit na ayon sa convention ay itinuturing na pangunahin. Hindi pinagkaiba ng Git ang main sa anumang iba pang branch sa antas ng system.

Paglipat mula master patungong main

Sa kasaysayan, ang default branch sa Git ay tinatawag na master. Noong Hunyo 2020, itinawag-pansin ng kilusang Black Lives Matter ang mga terminong master at slave sa industriya ng IT. Ipinahayag ng GitHub ang paglipat sa terminong main para sa default branch.

Mula Oktubre 2020, lahat ng bagong repositoryo sa GitHub ay nilikha gamit ang branch na main. Ipinatupad din ng GitLab at Bitbucket ang suporta para sa main bilang default na pangalan. Ang Git 2.28 (Hulyo 2020) ay nagdagdag ng opsyon na init.defaultBranch para i-configure ang pangalan ng default branch.

Sa teknikal, ang pagpapalit ng pangalan ng umiiral na branch mula master patungong main ay isang simpleng operasyon. Ang pangunahing hamon ay ang pag-update ng lahat ng reference sa mga configuration ng CI/CD, dokumentasyon, at lokal na repositoryo ng mga developer.

Upang palitan ang pangalan ng branch sa isang umiiral na repositoryo, isagawa ang:

# Lokal na pagpapalit ng pangalan ng master sa main
git branch -m master main

# Pag-update ng malayuang repositoryo
git push -u origin main

# Pag-alis ng lumang master sa server
git push origin --delete master

# Pag-update ng HEAD sa server
# (sa pamamagitan ng web interface ng GitHub: Settings → Branches → Default branch)

Papel ng main sa Git Flow at GitHub Flow

Git Flow at GitHub Flow ay magkaibang tinutukoy ang papel ng main branch. Ang pagpili ng modelo ay depende sa laki ng team, dalas ng release, at mga kinakailangan sa katatagan ng code.

Para sa pag-develop ng mobile app, ang pamantayan ay Git Flow, dahil ang pag-publish ng app sa App Store at Google Play ay may nakapirming release cycles. Ang GitHub Flow ay mas angkop para sa mga web project na may posibilidad ng deployment nang ilang beses sa isang araw.

GitHub Flow — pinasimpleng approach

Sa GitHub Flow ay walang develop branch. Lahat ng feature branches ay direktang ginagawa mula sa main, at pagkatapos makumpleto ay isinasama pabalik sa pamamagitan ng Pull Request. Bawat pagsasama sa main ay awtomatikong nagti-trigger ng deployment sa produksyon. Ang modelong ito ay nangangailangan ng mataas na automation ng pagsubok at disiplina ng team.

Sa GitHub Flow ay walang develop branch. Lahat ng feature branches ay direktang ginagawa mula sa main, at pagkatapos makumpleto ay isinasama pabalik sa pamamagitan ng Pull Request. Bawat pagsasama sa main ay awtomatikong nagti-trigger ng deployment sa produksyon. Ang modelong ito ay nangangailangan ng mataas na automation ng pagsubok at disiplina ng team.

Proteksyon ng main branch

Branch protection para sa main — sapilitang setting sa anumang komersyal na proyekto. Kung wala ito, ang aksidenteng push ay maaaring magpadala ng hindi tapos na code sa produksyon o masira ang gumaganang application para sa lahat ng user.

• Require pull request — bawal ang direktang push sa main. Lahat ng pagbabago sa pamamagitan ng PR na may review.
• Require approvals — minimum na 2 pag-apruba para sa pagsasama sa main (kung sakaling magkamali ang isang reviewer).
• Require status checks — lahat ng CI/CD checks ay dapat matagumpay bago ang pagsasama.
• Require up-to-date — PR ay dapat batay sa pinakabagong commit ng main.
• Include administrators — ang proteksyon ay nalalapat kahit sa mga may-ari ng repositoryo.
• Require signed commits — lahat ng commit sa main ay dapat pirmado ng GPG key.

Ang pag-configure ng lahat ng anim na panuntunan — pamantayan para sa mga mobile project na may audience na 10,000+ user. Para sa maliliit na proyekto, sapat na ang unang tatlong panuntunan.

Paghahambing ng mga antas ng proteksyon para sa iba't ibang uri ng proyekto

Ang antas ng proteksyon ng main ay depende sa laki ng proyekto. Ang isang startup ay maaaring gumana na may minimal na proteksyon, habang ang isang enterprise application ay nangangailangan ng maximum na paghihigpit.

Mga release at tag sa main

Pag-tag (tagging) — ang kasanayan ng paggawa ng pinangalanang reference sa partikular na commit sa main. Ang bawat tag ay katumbas ng bersyon ng application na inilabas sa produksyon. Ito ay nagbibigay-daan sa mabilis na paglipat sa anumang nakaraang release para sa debugging o patch.

Ang pamantayan sa pagpapangalan ng tag sa pag-develop ng mobile app — SemVer (Semantic Versioning): v1.2.3, kung saan ang unang numero ay major version (breaking changes), pangalawa — minor (mga bagong feature), pangatlo — patch (mga pag-aayos).

Ang tag ay ginagawa pagkatapos isama ang release branch sa main. Ang commit na ito ay bubuuin sa CI/CD, pipirmahan, at ipapadala sa app store. Kung may matuklasang error sa tag, gagawin ang hotfix branch mula sa tag na iyon.

# Paggawa ng annotated release tag
git tag -a v2.4.1 -m "Release version 2.4.1"

# Pagpapadala ng tag sa server
git push origin v2.4.1

# Pagtingin ng lahat ng tag sa repositoryo
git tag -l "v2.*"

# Paggawa ng hotfix branch mula sa isang partikular na tag
git checkout -b hotfix/crash-fix v2.4.1

Herarkiya ng branches sa Git Flow

Ang pag-unawa sa herarkiya ng branches sa Git Flow — pundasyon para sa tamang organisasyon ng collaborative development. Ang bawat uri ng branch ay may sariling source, layunin, at mga panuntunan sa pagsasama.

• Main (Level 1) — root branch, naglalaman lamang ng mga release version. Ginagawa sa pag-initialize ng repositoryo.
• Develop (Level 2) — ginagawa mula sa main sa pagsisimula ng proyekto. Naglalaman ng integration code ng lahat ng feature.
• Feature (Level 3) — ginagawa mula sa develop. Nakahiwalay na pag-develop ng indibidwal na feature.
• Release (Level 2) — ginagawa mula sa develop. Paghahanda ng partikular na release para ilabas.
• Hotfix (Level 2) — ginagawa mula sa main. Agarang pag-aayos ng kritikal na error sa produksyon.

Mahalagang panuntunan: ang feature ay hindi kailanman direktang isinasama sa main. feature → develop → release → main — ang tamang chain ng pagsasama. Ang paglabag sa panuntunang ito ay nag-aalis ng kahulugan sa buong modelo ng Git Flow.

Mga halimbawa ng command para sa pagtatrabaho sa main

Isaalang-alang ang scenario: natapos ng team ang paghahanda ng release v2.5.0. Ang release branch ay napatunayan na at handa nang isama sa main. Pagkatapos ng pagsasama, ginagawa ang tag at inilalathala ang release.

# Paglipat sa main at pag-update
git checkout main
git pull origin main

# Pagsasama ng napatunayang release branch
git merge --no-ff release/2.5.0

# Paggawa ng release tag
git tag -a v2.5.0 -m "Release 2.5.0 - Payment integration"

# Pagpapadala ng main at tag sa server
git push origin main --tags

Ang flag na --no-ff (no fast-forward) ay ginagarantiyahan ang paggawa ng merge commit, kahit na ang pagsasama ay maaaring gawin sa pamamagitan ng simpleng paglipat ng pointer. Ito ay nagpapanatili ng impormasyon na ang mga pagbabago ay nagmula sa release branch, na nagpapadali sa pagsusuri ng kasaysayan.

Pagtatrabaho sa hotfix sa pamamagitan ng main

Kung may matuklasang kritikal na error sa produksyon, ang proseso ay naiiba sa ordinaryong release. Ang hotfix ay ginagawa mula sa main, at pagkatapos ng pag-aayos ay isinasama pareho sa main at sa develop.

Kung may matuklasang kritikal na error sa produksyon, ang proseso ay naiiba sa ordinaryong release. Ang hotfix ay ginagawa mula sa main, at pagkatapos ng pag-aayos ay isinasama pareho sa main at sa develop.

# Paggawa ng hotfix branch mula sa main
git checkout main
git checkout -b hotfix/2.5.1-crash-fix

# Pag-aayos at pag-commit
git add src/fix/
git commit -m "Fix crash on login screen"

# Pagsasama ng hotfix pabalik sa 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

# Pagsasama rin ng hotfix sa develop
git checkout develop
git merge --no-ff hotfix/2.5.1-crash-fix
git push origin develop

# Pag-alis ng hotfix branch
git branch -d hotfix/2.5.1-crash-fix