Git Flow, GitHub Flow, at trunk-based: aling Git workflow ang piliin

Ano ang Git workflow at bakit mahalaga ang pagpili nito

Ang Git workflow ay kasunduan ng team tungkol sa kung anong mga branch ang umiiral, saan ginagawa ang mga ito, saan sila nagme-merge, at kung ano ang itinuturing na handa para sa release. Hindi ito ipinipilit ng Git mismo, kaya kung walang kasunduan, kanya-kanya ang bawat isa. Pagkalipas ng isang buwan, sampu-sampung branch na ang nasa repository, hindi malinaw kung ano ang naka-deploy, at nagiging oras-oras na conflict ang mga merge.

Ang pinakakilalang mga modelo ay ang Git Flow, GitHub Flow (isang bersyon ng Feature Branch Workflow), at trunk-based development. Hindi ito "luma at bago", kundi mga kasangkapan para sa magkakaibang kondisyon: gaano kadalas kayo naglalabas ng release, ilang bersyon ng produkto ang sabay ninyong sinusuportahan, at gaano ka-develop ang automated tests.

Git Flow: modelo na may develop at release branch

Inilarawan ni Vincent Driessen ang Git Flow noong 2010. Nakasalalay ang modelo sa dalawang pangmatagalang branch:

• main (sa mas lumang project, master): code na nai-release lang; bawat commit dito ay tumutugma sa release at may tag;
• develop: integration branch kung saan pinagsasama ang mga tapos na feature para sa susunod na release.

At tatlong uri ng pansamantalang branch:

Git Flow gamit ang purong Git

Ganito ang ikot ng isang feature at isang release:

# feature
git switch develop
git switch -c feature/cart-discounts
# ... mga commit ...
git switch develop
git merge --no-ff feature/cart-discounts
git branch -d feature/cart-discounts

# release
git switch -c release/1.4.0 develop
# ... pag-aayos ng bersyon at bug fix ...
git switch main
git merge --no-ff release/1.4.0
git tag -a v1.4.0 -m "Release 1.4.0"
git switch develop
git merge --no-ff release/1.4.0
git branch -d release/1.4.0

Mahalaga ang flag na --no-ff sa modelong ito: gumagawa ito ng merge commit kahit kaya ang fast-forward, kaya nakikita pa rin sa history kung aling mga commit ang kabilang sa iisang feature o release.

Extension na git-flow

Para hindi na i-type nang manwal ang mga sunod-sunod na command, may utility na git-flow (karaniwang inii-install ang maintained na fork, na madalas tawaging git-flow-avh sa mga package manager). Nagdadagdag ito ng mga subcommand:

git flow init -d
git flow feature start cart-discounts
git flow feature finish cart-discounts
git flow release start 1.4.0
git flow release finish 1.4.0
git flow hotfix start 1.4.1
git flow hotfix finish 1.4.1

Itinatanong ng git flow init ang mga pangalan ng branch at prefix (gamit ang -d, tinatanggap ang mga default), at ginagawa ng mga finish command ang lahat ng kinakailangang merge, naglalagay ng tag, at binubura ang pansamantalang branch. Maraming GUI client ng Git ang sumusuporta rin sa Git Flow gamit ang mga button.

Bentahe at disbentahe ng Git Flow

Mga bentahe: malinaw na istruktura, malinaw ang estado ng code (main ang nasa kliyente; develop ang susunod na bersyon), hiwalay na yugto ng pagpapatatag ng release, at madaling suporta sa hotfix. Angkop ito sa mobile app, boxed software, library, at firmware, kung saan dumadaan ang release sa review ng app store o naka-install sa kliyente.

Mga disbentahe: maraming branch at merge, ang mga long-lived na feature branch ay nag-iipon ng pagkakaiba sa develop, at madaling makalimutan ang dobleng merge ng release at hotfix. Para sa web service na nagde-deploy ng ilang beses kada araw, nagiging burukrasya ang release branch. Mismong may-akda ng modelo ang nagdagdag ng tala noong 2020: para sa software na tuloy-tuloy na naihahatid, mas mainam tingnan ang mas simpleng approach gaya ng GitHub Flow.

GitHub Flow: maiikling branch at pull request

Ang GitHub Flow ay magaang bersyon ng Feature Branch Workflow. Kasya ang mga tuntunin sa ilang punto:

1. Laging nasa maayos na estado ang main at handa para i-deploy.
2. Anumang trabaho ay nasa branch mula sa main na may malinaw na pangalan.
3. Regular na ipinapadala ang branch at binubuksan ang pull request (merge request) para sa talakayan.
4. Pagkatapos ng review at berdeng CI, sinasama ang branch sa main.
5. Ang anumang isinama sa main ay agad na dine-deploy.

git switch main
git pull
git switch -c feature/new-payment
# ... mga commit na may malinaw na mensahe ...
git push -u origin feature/new-payment
# magbukas ng pull request, dumaan sa review at CI, i-merge sa main

Mga bentahe: iisang pangmatagalang branch, kaunting tuntunin, mabilis na daan mula sa ideya hanggang production, at natural na code review. Mga disbentahe: walang built-in na lugar para sa sabay na suporta ng maraming bersyon o pagpapatatag bago ang release, at kung walang magagandang automated test, nananatiling hangarin lang ang "laging handa ang main".

May katulad na approach na may dagdag na branch para sa environment (halimbawa staging at production) na tinatawag minsang GitLab Flow. Kapaki-pakinabang ito kapag hindi agad napupunta sa production ang deploy, kundi ayon sa iskedyul o pagkatapos ng manwal na pagsusuri.

Trunk-based development

Sa trunk-based development, lahat ng developer ay madalas na nag-i-integrate ng pagbabago sa iisang branch (ang trunk, ibig sabihin main) — kahit isang beses sa isang araw. Kung may branch man, oras lang ang tagal nito, hindi linggo. Ang hindi pa tapos na functionality ay napupunta sa main pero nakatago sa likod ng feature flag:

if (featureFlags.isEnabled("new-checkout", user)) {
    renderNewCheckout();
} else {
    renderOldCheckout();
}

Ang pangunahing bentahe: halos walang malalaking conflict, dahil maliit ang mga pagbabago at agad na sinasama habang sariwa pa sa lahat ang konteksto. Angkop ang modelong ito sa mga may karanasang team na may mabilis na CI at mataas na test coverage. Puwede pa ring gumawa ng release branch, pero galing sa trunk mismo bago ang paglalabas, at ang mga ayos ay unang inilalagay sa trunk, saka inililipat gamit ang cherry-pick.

Mga disbentahe: kailangan ng disiplina at imprastraktura: mabilis na test, flags, at monitoring. Nakakatakot sa baguhan ang pag-commit sa main araw-araw, at ang mahinang CI ay gagawing trunk na laging sira. Kailangan ding tanggalin sa tamang panahon ang mga flag, dahil kung hindi, mag-iipon ang code ng mga patay na sangay.

Paghahambing ng Git Flow, GitHub Flow, at trunk-based

Paano pumili ng git workflow para sa team

Sagutin ang ilang tanong:

• Kailangan bang suportahan ang ilang nai-release na bersyon? Kung nasa 2.x at 3.x pa rin ang mga kliyente at kailangan ng dalawa ang ayos, Git Flow o trunk-based na may release branch.
• Gaano kadalas kayo mag-deploy? Kada quarter, hindi makakaabala ang Git Flow. Araw-araw, piliin ang GitHub Flow o trunk-based.
• Gaano kayo nagtitiwala sa test ninyo? Kung mabagal ang CI at mahina ang coverage, magsimula sa GitHub Flow na may mandatory na review, at unti-unting paikliin ang mga branch.
• Gaano kalaki at ka-experienced ang team? Sa maliit na team at mga baguhan, pinakasimple ang GitHub Flow: isang tuntunin na "laging gumagana ang main" at pull request para sa lahat.

Praktikal na payo: huwag piliin ang Git Flow dahil "ganoon ang nakasanayan". Magsimula sa pinakasimpleng proseso na sumasagot sa pangangailangan ninyo, at dagdagan lang ito kapag may tiyak nang problema, halimbawa kailangan ng yugto ng pagpapatatag o suporta sa lumang bersyon.

Mga tuntuning gumagana sa anumang workflow

• Protektahan ang main sa server: bawal ang direktang push, kailangan ng review at berdeng CI bago mag-merge.
• Magkasundo sa mga pangalan ng branch: feature/, fix/, hotfix/ kasama ang numero ng task.
• Panatilihing maikli ang branch: habang tumatagal ang branch, lalong masakit i-merge. Regular na kunin ang main sa sarili ninyong branch gamit ang merge o rebase.
• Pumili ng estratehiya sa pag-merge ng pull request (merge commit, squash, o rebase) at gamitin ito nang pare-pareho.
• Markahan ang mga release ng annotated tag ayon sa semantic versioning.

Hotfix sa bawat modelo: isang bug, tatlong proseso

Pinakamalinaw ang pagkakaiba ng mga approach kapag ayusin ang urgent na problema sa production.

Sa Git Flow, gagawa ng hotfix/1.4.1 mula sa main; pagkatapos ng ayos, isasama ang branch sa main na may tag na v1.4.1, at kailangan ding isama sa develop (o sa kasalukuyang release branch, kung meron). Ang nakalimutang pangalawang merge ay klasikong pagkakamali: sa susunod na release, "babalik" ang bug.

git switch -c hotfix/1.4.1 main
git commit -am "Ayusin ang kuwenta ng diskuwento"
git switch main && git merge --no-ff hotfix/1.4.1
git tag -a v1.4.1 -m "Hotfix 1.4.1"
git switch develop && git merge --no-ff hotfix/1.4.1

Sa GitHub Flow, ang hotfix ay ordinaryong maikling branch mula sa main na may pull request na binibigyan ng prayoridad sa review. Pagkatapos ng merge, mapupunta ito sa production sa parehong awtomatikong deploy, walang hiwalay na proseso.

Sa trunk-based, unang ini-commit ang ayos sa trunk, at kung may release branch na tumatakbo sa production, ililipat ang commit dito gamit ang git cherry-pick -x <hash>. Idinadagdag ng flag na -x ang reference sa orihinal na commit sa mensahe, para makita ang koneksyon sa history. Kung ang problema ay nasa bagong function, kadalasan sapat nang i-off ang feature flag nito, nang hindi ginagalaw ang code.

Paano sumagot sa interview ng "anong Git workflow ang ginamit ninyo"

Hindi kabisadong pangalan ang tinitingnan ng interviewer, kundi ang pag-unawa sa mga trade-off. Magandang sagot: banggitin ang modelo, ilarawan kung paano gumagana ang mga branch at review dito, at ipaliwanag kung bakit ito angkop sa project. Halimbawa: "Gumamit kami ng GitHub Flow: mga branch mula sa main, pull request na may mandatory na review at CI, at awtomatikong deploy pagkatapos ng merge. Hindi kami gumamit ng Git Flow, dahil ilang beses kada linggo kaming naglalabas at magpapabagal lang ang release branch." Dagdag na puntos kung maibabahagi rin ninyo kung ano ang babaguhin ninyo kapag lumaki na ang proseso.

Buod

Ang Git Flow ay mahigpit na modelo na may develop, release, at hotfix branch, mainam para sa produktong may nakatakdang bersyon at sabay na suporta ng ilang release. Mas simple ang GitHub Flow at angkop sa karamihan ng web project, habang ang trunk-based development ang nagbibigay ng pinakamabilis na takbo pero nangangailangan ng hinog na CI at feature flags. Piliin ang workflow ayon sa dalas ng release at kalidad ng test, hindi ayon sa uso. Ang tatlong approach kasama ang kanilang mga command at karaniwang pagkakamali ay itinuturo nang praktikal sa kursong Git namin.