Git Flow: ano ito, modelo ng pagsasanga at paggamit sa mga proyekto

Ano ang Git Flow?

Git Flow — ay isang modelo ng pagsasanga ng Git na nagtatakda ng mahigpit na istruktura ng mga sangay at mga patakaran ng pagsasanib para sa pamamahala ng pag-unlad, mga release at pag-aayos. Inilathala ni Vincent Driessen ang artikulong 'A successful Git branching model' noong Enero 2010 at mula noon ang Git Flow ay naging de facto na pamantayan sa pag-unlad ng korporasyon ng Java at .NET. Ang pangunahing ideya — hatiin ang code sa limang uri ng sangay na may iba't ibang antas ng katatagan.

Ayon sa Atlassian Git Tutorials, 2024, ang Git Flow ay batay sa dalawang permanenteng sangay: main (dating master) at develop. Lahat ng iba pang sangay ay pansamantala: feature, release, hotfix. Bawat uri ng sangay ay may malinaw na tinukoy na siklo ng buhay at mga patakaran ng pagsasanib. Sa mobile development, ang Git Flow ay ginagamit sa mga proyektong may regular na siklo ng release (2–4 na linggo) at suporta para sa maraming bersyon.

Git Flow ay naiiba sa mga simpleng modelo (GitHub Flow) dahil nangangailangan ito ng hiwalay na sangay ng develop para sa integrasyon. Nagdaragdag ito ng isang hakbang sa proseso ng pagsasanib, ngunit nagbibigay ng karagdagang paghihiwalay ng mga hindi tapos na feature mula sa code na handa na para sa release.

Vincent Driessen at ang kasaysayan ng Git Flow

Noong 2010, inilathala ni Vincent Driessen ang post na 'A successful Git branching model', na naging isa sa mga pinaka-binanggit sa kasaysayan ng Git. Ang modelo ay nilikha para sa isang proyekto na may nakapirming mga release at parallel na suporta sa bersyon. Noong 2020, inamin ni Driessen na ang Git Flow ay luma na para sa mga modernong CI/CD na kasanayan, ngunit ang modelo ay nananatiling may kaugnayan para sa mga proyektong may mahabang siklo ng release at pangangailangan na suportahan ang mga lumang bersyon.

# Pagsisimula ng Git Flow
git flow init

# Paglikha ng feature na sangay
git flow feature start "add-auth"

# Pagkumpleto ng feature na sangay (pagsasanib sa develop)
git flow feature finish "add-auth"

# Paglikha ng release
git flow release start "1.2.0"
git flow release finish "1.2.0"

Sangay ng Main: release code at pag-tag

Main (dating master) — pangunahing sangay na naglalaman lamang ng release code na handa para sa deploy. Bawat commit sa main ay dapat tumugma sa isang tiyak na bersyon ng produkto na minarkahan ng tag sa format ng semantic versioning, halimbawa v1.0.0, v1.1.0. Walang direktang pag-unlad sa main na isinasagawa — ang mga pagbabago ay pumapasok dito lamang sa pamamagitan ng release o hotfix na mga sangay.

Ayon sa semver.org, 2024, ang mga tag sa main ay gumagamit ng format na MAJOR.MINOR.PATCH. Ang MAJOR ay dinadagdagan para sa mga hindi tugmang pagbabago sa API, MINOR — para sa pagdaragdag ng functionality na may backward compatibility, PATCH — para sa pag-aayos ng bug. Sa Git Flow, bawat finish release ay awtomatikong lumilikha ng commit sa main na may tag ng bersyon.

Main — ang tanging sangay na nade-deploy sa produksyon. Para sa mga mobile project, nangangahulugan ito na sa push sa main, ang pipeline ng pagbuo ng App Bundle o IPA at pag-publish sa Google Play / App Store ay magsisimula. Sa mga setting ng CI/CD ng GitLab, ang main ay protektado laban sa force-push at pagbura.

Semantic versioning at mga tag

Bawat commit sa main ay sinamahan ng isang tag sa SemVer format: vMAJOR.MINOR.PATCH. MAJOR — para sa mga hindi tugmang pagbabago sa API, MINOR — para sa bagong functionality na may backward compatibility, PATCH — para sa pag-aayos ng bug. Halimbawa: v2.1.0 ay nangangahulugang pangalawang major release na may mga bagong feature at walang pag-aayos ng bug. Sa Git Flow, ang mga tag ay awtomatikong nililikha sa finish release o hotfix sa pamamagitan ng utos na git flow release finish.

Sangay ng Develop: linya ng integrasyon ng pag-unlad

Develop — pangalawang permanenteng sangay ng Git Flow, na nilayon para sa integrasyon ng lahat ng natapos na feature. Pinagsasanib ng mga developer ang mga feature na sangay sa develop pagkatapos makaraan ang code review at mga pagsusuri ng CI/CD. Ang develop ay naglalaman ng pinakabagong matatag na bersyon ng code na kasama ang lahat ng ipinatupad na feature ng kasalukuyang sprint.

Ayon sa DataSift Git Flow Guide, 2024, ang develop ay maaaring pansamantalang hindi matatag dahil sa hindi natapos na mga integrasyon. Upang maiwasan ang mga problema, ang mga pangkat ay nagsasagawa ng Continuous Integration (CI): bawat feature bago isanib sa develop ay sumasailalim sa isang kumpletong hanay ng mga pagsubok. Kung nabigo ang CI — inaayos ng developer ang code hanggang sa susunod na pagsasanib. Ang develop ay palaging nakaugnay sa kasalukuyang bersyon ng main: kaagad pagkatapos ng release, ang develop ay naka-sync sa main sa pamamagitan ng pagsasanib.

Mga sangay ng Feature: pagbuo ng bagong functionality

Mga sangay ng feature — pansamantalang mga sangay para sa pagbuo ng mga indibidwal na feature, pag-aayos ng bug o eksperimento. Bawat feature na sangay ay nilikha mula sa develop at pagkatapos makumpleto ay isinasanib pabalik sa develop. Ang pangalan ng feature na sangay ay karaniwang naglalaman ng numero ng gawain o maikling paglalarawan: feature/APP-123-add-oauth, feature/redesign-profile. Sa Git Flow, ang mga feature na sangay ay maaaring umiral nang walang limitasyong oras.

Ayon sa Pro Git Book, 2024, ang mga feature na sangay ay isang isolated na kapaligiran ng pag-unlad: ang mga pagbabago sa isang sangay ay hindi nakakaapekto sa iba hanggang sa sandali ng pagsasanib. Sa mga mobile project, ang mga feature na sangay ay naka-sync sa develop sa pamamagitan ng rebase o merge upang maiwasan ang malalaking conflict sa pagkumpleto. Inirerekomenda na i-rebase ang feature na sangay sa develop bago lumikha ng MR.

# Manu-manong paglikha ng feature na sangay (nang walang git flow)
git checkout -b feature/APP-142-add-auth develop
git commit -m "Add OAuth2 authentication with Google"
git push origin feature/APP-142-add-auth

# Paglikha ng MR sa GitLab sa pamamagitan ng CLI
glab mr create \
    --source-branch "feature/APP-142-add-auth" \
    --target-branch "develop" \
    --title "Add OAuth2 authentication"

Mga sangay ng Release: paghahanda ng release

Mga sangay ng release — pansamantalang mga sangay na nilikha mula sa develop para sa paghahanda ng release. Kapag ang develop ay naglalaman ng sapat na hanay ng mga feature para sa isang bagong bersyon, ang pangkat ay lumilikha ng sangay na release/X.Y.Z (halimbawa, release/2.1.0). Sa sangay na ito, tanging mga huling pagbabago ang ginagawa: pagtaas ng bersyon, pag-update ng lokalisasyon, huling pagsubok, pag-aayos ng kritikal na bug.

Ayon sa Atlassian Git Tutorials, 2024, ang sangay ng release ay lumulutas ng isang pangunahing problema: paghihiwalay ng mga huling pagbabago mula sa parallel na pag-unlad. Habang ang release ay inihahanda para sa paglabas, sa develop ay patuloy na pinagsasanib ang mga bagong feature para sa susunod na release. Pagkatapos makumpleto, ang sangay ng release ay isinasanib sa main (na may tag) at sa develop (upang i-sync ang pagtaas ng bersyon).

Mga sangay ng Hotfix: agarang pag-aayos sa produksyon

Mga sangay ng hotfix — pansamantalang mga sangay para sa agarang pag-aayos ng kritikal na bug sa produksyon. Ang tanging uri ng sangay ng Git Flow na nilikha mula sa main, hindi mula sa develop. Format ng pangalan: hotfix/X.Y.Z+1 (halimbawa, hotfix/2.1.1). Pagkatapos makumpleto, ang sangay ng hotfix ay isinasanib nang sabay-sabay sa main (bilang bagong patch release) at sa develop (upang ang pag-aayos ay hindi mawala sa mga susunod na release).

Ayon sa DataSift Git Flow Guide, 2024, ang mga sangay ng hotfix ay dapat na kasing-ikli hangga't maaari — pag-aayos at pagsubok lamang. Ang hotfix ay hindi dapat magsama ng mga bagong feature o refactoring. Sa mobile development, ang hotfix ay ginagamit para sa pag-aayos ng kritikal na crash (crash rate > 0.1%), mga kahinaan sa seguridad o mga blocking bug sa App Store.

Mga kalamangan at kahinaan ng Git Flow para sa mobile development

Git Flow ay nagbibigay ng malinaw na istruktura na lalong kapaki-pakinabang para sa malalaking pangkat at mga proyektong may regular na release. Mga kalamangan: paghihiwalay ng hindi tapos na feature sa mga feature na sangay, posibilidad ng paghahanda ng release nang hindi hinaharangan ang pag-unlad, suporta para sa maraming bersyon sa pamamagitan ng hotfix. Mga kahinaan: pagiging kumplikado para sa mga nagsisimula, pangangailangan para sa regular na rebase ng mga feature na sangay, conflict sa mga sangay na matagal ang buhay.

Ayon sa Martin Fowler, 2024, ang pangunahing kahinaan ng Git Flow — mga feature na sangay na matagal ang buhay. Kung ang isang feature ay binuo nang 2+ linggo nang walang sync sa develop, ang conflict sa pagsasanib ay nagiging malaki. Para sa mga mobile project, inirerekomenda na i-sync araw-araw ang feature na sangay sa pamamagitan ng rebase sa develop.

Git Flow ay hindi inirerekomenda para sa mga proyektong may Continuous Deployment (bawat commit sa main → sa produksyon). Para sa mga ganitong proyekto, ang GitHub Flow o Trunk-Based Development ay nagbibigay ng mas simple at mas mabilis na modelo. Ngunit para sa mga proyektong may siklo ng release at suporta para sa mga lumang bersyon, ang Git Flow ay nananatiling pinakamainam na pagpipilian.

Kailan nakakasama ang Git Flow sa pangkat

Ang Git Flow ay nagiging problema sa tatlong kaso: pangkat na mas mababa sa 5 tao (labis na pagiging kumplikado), Continuous Deployment (pagkaantala sa paghahatid), kawalan ng disiplina sa rebase (mga feature na sangay na matagal ang buhay ay lumilikha ng mga conflict sa pagsasanib). Kung ang pangkat ay gumugugol ng higit sa 20% ng oras sa pagsasanib ng mga sangay at paglutas ng mga conflict — ang Git Flow ay hindi angkop para sa pangkat na iyon, kahit na sa malaking sukat.

Mga alternatibo sa Git Flow: GitHub Flow at Trunk-Based Development

Mga alternatibo sa Git Flow ay nag-aalok ng mas simpleng proseso para sa mga pangkat na nagsasagawa ng CI/CD. GitHub Flow ay gumagamit lamang ng isang permanenteng sangay (main) at mga feature na sangay. Bawat feature ay nilikha mula sa main, pagkatapos ng review at CI ay isinasanib pabalik sa main at agad na nade-deploy. Ang GitHub Flow ay mas simple, ngunit hindi sumusuporta sa paghihiwalay ng hindi tapos na feature at parallel na paghahanda ng release.

Ayon sa GitHub Docs, 2024, ang Trunk-Based Development (TBD) ay mas malayo pa: lahat ng developer ay nagtatrabaho sa isang sangay (trunk), gamit ang mga feature na sangay na maikli ang buhay na 1–2 araw. Ang feature toggles (switch ng feature) ay kumokontrol sa visibility ng hindi tapos na code. Ang TBD ay nangangailangan ng mataas na disiplina sa CI/CD at automation ng pagsubok.

• GitHub Flow — isang main + mga feature na sangay, perpekto para sa CI/CD at maliliit na pangkat
• GitLab Flow — pinapalawak ang Git Flow gamit ang mga sangay ng kapaligiran (staging, production)
• Trunk-Based Development — isang sangay + feature toggles, maximum CI/CD, minimum na pagsasanib
• One Flow — pinasimpleng Git Flow na walang sangay ng develop, main + feature + release lamang