Hotfix Branch: ano ito, paano gumawa at gamitin sa mobile development

Ano ang Hotfix Branch?

Hotfix Branch — ay isang pansamantalang branch sa Git, na ginagawa para sa agarang pag-aayos ng mga kritikal na depekto sa production na tumatakbo. Hindi tulad ng mga feature branch, na sumasanga mula sa develop at nabubuhay ng ilang araw o linggo, ang hotfix ay ginagawa mula sa main/master at umiiral nang eksakto hangga't kailangan para ayusin ang bug.

Ang pangunahing gawain ng hotfix — pagbawas ng oras sa pagitan ng pagtuklas ng kritikal na error at pag-aayos nito sa production. Hindi hinihintay ng team ang pagtatapos ng kasalukuyang sprint o release cycle, agad nilang inilalabas ang patch. Ito ay lalong mahalaga para sa mga mobile application, kung saan ang kritikal na bug ay maaaring humarang sa mga user at humantong sa pagbaba ng bilang ng mga user.

Ayon sa datos ng Google Play Console, ang average na oras ng moderasyon ng update sa Google Play ay 2 hanggang 24 na oras. Para sa App Store ang express review ay maaaring tumagal ng 1 hanggang 4 na oras. Ang mga hotfix branch ay nagpapahintulot na ihanda ang pag-aayos bago pa matapos ang moderasyon at ilunsad ito kaagad pagkatapos ng aprobasyon.

Prinsipyo ng paggana ng Hotfix

Ang proseso ng hotfix ay binubuo ng tatlong hakbang: paggawa ng branch mula sa main, pag-aayos, at pagsasama pabalik sa main at develop. Ang pangunahing pagkakaiba sa ordinaryong pag-aayos — ang hotfix ay palaging isinasama sa parehong branch, upang hindi mawala ang pag-aayos sa susunod na release.

Ang team ay hindi dapat magdagdag ng bagong functionality o refactoring sa hotfix. Tanging ang tiyak na pag-aayos, minimal na kinakailangan para maalis ang kritikal na problema. Ang anumang paglihis sa patakarang ito ay nagpapataas ng panganib ng regression at nagpapahaba ng oras ng paglabas ng patch.

Kailan kailangan ang Hotfix

Hotfix ay kailangan sa tatlong sitwasyon: kritikal na bug na humaharang sa mga user (crash, pagkawala ng data), kahinaan sa seguridad na nangangailangan ng agarang pagsasara, o sirang kritikal na business logic (pagbabayad, pagpapatotoo). Kung ang bug ay hindi kritikal — maaari itong ayusin sa loob ng ordinaryong release cycle sa pamamagitan ng develop.

Para sa mga mobile application ang hotfix ay maaari ring magsama ng mga pagbabago sa server, kung pinapayagan ng arkitektura ang malayuang paglipat ng mga feature (feature flags). Sa kasong ito, ang hotfix branch ay maaaring minimal o hindi na kailangan, kung ang pag-aayos ay ginagawa sa panig ng server.

Mga modelo ng branching at lugar ng Hotfix

Hindi lahat ng modelo ng branching ay sumusuporta sa mga hotfix branch. Ang tradisyonal na Git Flow ay nagbibigay ng hotfix bilang isang ganap na uri ng branch, habang ang mas modernong mga diskarte (GitHub Flow, Trunk-based) ay nalulutas ang problema ng mga emergency na pag-aayos nang iba.

Git Flow at Hotfix

Git Flow — ay ang tanging modelo kung saan ang hotfix ay isang built-in na uri ng branch kasama ng feature at release. Sa Git Flow ang hotfix ay ginagawa mula sa main, at pagkatapos ng pagkumpleto ay isinasama sa parehong main (may tag ng bersyon) at develop. Tinitiyak nito na ang pag-aayos ay hindi mawawala sa susunod na release.

GitHub Flow at Trunk-based

GitHub Flow ay hindi gumagamit ng hiwalay na uri ng branch para sa hotfix. Sa halip, ang developer ay gumagawa ng ordinaryong feature branch mula sa main, nagsasagawa ng pag-aayos, at nagbubukas ng Pull Request. Pagkatapos ng review at CI checks, ang branch ay isinasama sa main at agad na ilinalunsad. Bentahe — pagiging simple, disadvantage — kawalan ng hiwalay na channel para sa mga agarang pag-aayos.

Trunk-based development ay nalulutas ang problema ng hotfix sa pamamagitan ng direktang commit sa main (para sa mga kritikal na kaso) na may mandatoryong post-factum review. Ang diskarteng ito ay nangangailangan ng mataas na disiplina ng team at maaasahang automated na mga test, dahil ang mga pagbabago ay diretso sa production.

Paano gumawa ng Hotfix Branch

Paggawa ng hotfix ay nagsisimula sa paglipat sa pangunahing branch at paggawa ng bagong branch na may prefix na hotfix/. Tingnan natin ang proseso ng hakbang-hakbang sa halimbawa ng pag-aayos ng kritikal na bug sa isang mobile application.

Paggawa ng branch mula sa main

Unang hakbang — lumipat sa main at tiyaking napapanahon ang branch. Pagkatapos ay gumawa ng hotfix branch na may malinaw na pangalan na sumasalamin sa esensya ng pag-aayos.

# Lumipat sa main at kunin ang pinakabagong mga pagbabago
git checkout main
git pull origin main

# Gumawa ng hotfix branch
git checkout -b hotfix/crash-on-login

Pagkatapos gawin ang branch, maaaring isagawa ang pag-aayos. Mahalaga: ang hotfix ay dapat maglaman ng minimal na bilang ng mga pagbabago. Huwag mag-refactor ng code o magdagdag ng mga bagong feature — tanging ang tiyak na pag-aayos na nag-aalis ng problema.

Pag-record ng pag-aayos

Commit sa hotfix ay dapat may nagbibigay-kaalaman na mensahe na malinaw na naglalarawan ng problema at solusyon nito. Format: uri(lugar): maikling paglalarawan + link sa gawain sa tracker.

# Idagdag ang mga binagong file
git add src/ui/login/LoginActivity.kt

# Gumawa ng commit na may paglalarawan
git commit -m "fix(login): handle null intent on activity resume

Fixes CRASH-142: NullPointerException when LoginActivity
receives onNewIntent after being destroyed by system"

Ang mensahe ng commit ay dapat maglaman ng paglalarawan ng problema at link sa gawain. Ito ay nagpapadali sa paghahanap sa kasaysayan at tumutulong sa mga kasamahan na maunawaan kung ano ang naayos at bakit. Para sa mga mobile project karaniwang isinasama rin ang bersyon ng application kung saan natagpuan ang bug.

Pagsasama sa main at develop

Huling hakbang — isama ang hotfix pabalik sa main (na may tag ng bagong patch version) at sa develop (upang manatili ang pag-aayos sa susunod na release). Una ay ginagawa ang pagsasama sa main na may tag, pagkatapos ay ang pagsasama sa develop.

# Isama sa main at gumawa ng tag
git checkout main
git merge --no-ff hotfix/crash-on-login
git tag -a v2.3.1 -m "Hotfix: crash on login"

# Isama sa develop
git checkout develop
git merge --no-ff hotfix/crash-on-login

# Ipadala ang mga pagbabago sa server
git push origin main --tags
git push origin develop

Ang bandila na --no-ff ay tinitiyak ang paggawa ng merge commit, kahit na ang hotfix ay maaaring ilapat sa pamamagitan ng fast-forward. Ito ay nagpapanatili ng impormasyon na isinagawa ang emergency na pag-aayos at nagpapadali sa pagsusuri ng kasaysayan sa hinaharap.

Pagkakaiba ng Hotfix sa Feature at Release

Hotfix ay pangunahing naiiba sa feature at release branch sa layunin, tagal ng buhay, at mga patakaran ng pagsasama. Ang pag-unawa sa mga pagkakaibang ito ay mahalaga para sa tamang organisasyon ng mga proseso ng Git sa team.

Ang feature branch ay para sa bagong functionality. Nabubuhay mula ilang araw hanggang ilang linggo, ginagawa mula sa develop at isinasama pabalik sa develop. Ang feature ay maaaring maglaman ng maraming commit, kabilang ang mga eksperimental, na mamaya ay pinipiga sa pamamagitan ng squash o rebase.

Ang release branch ay naghahanda ng release para ilunsad. Ginagawa mula sa develop, dito inaayos ang mga bug na natagpuan sa proseso ng stabilisasyon, at hindi tumatanggap ng bagong functionality. Pagkatapos ng pagkumpleto, ang release ay isinasama sa main (may tag) at develop.

Hotfix ay ginagawa at isinasama nang direkta sa main, na lumalampas sa develop (bagaman pagkatapos ng pag-aayos ay nagsi-sync din sa develop). Naglalaman ng minimal na bilang ng mga pagbabago at umiiral sa minimal na oras. Kung ang feature o release ay maaaring ipagpaliban hanggang sa susunod na cycle, ang hotfix — hindi.

Para sa mobile development ang pagkakaibang ito ay lalong mahalaga: App Store at Google Play ay nagpapahintulot na maglabas ng mga patch version nang hiwalay sa mga pangunahing release. Ang hotfix branch ay tinitiyak ang proseso kung saan ang patch release ay hindi nahahalo sa mga hindi tapos na feature.

Mga karaniwang pagkakamali sa paggamit ng Hotfix

Mga pagkakamali sa paggamit ng hotfix ay maaaring magpawalang-bisa sa mga bentahe ng emergency na pag-aayos. Tingnan natin ang limang pinakakaraniwang problema na lumalabas sa mga team na gumagamit ng Git Flow.

• Paggawa ng hotfix mula sa develop — kung ang hotfix ay ginawa mula sa develop, maaaring pumasok ang mga hindi tapos na feature sa patch. Ang hotfix ay dapat gawin lamang mula sa main upang matiyak na ang pag-aayos ay naglalaman lamang ng matatag na code.
• Maraming pag-aayos sa isang hotfix — bawat pag-aayos ay dapat nasa hiwalay na hotfix branch. Ang paghahalo ng maraming bug sa isang branch ay nagpapahirap sa code review, nagpapataas ng panganib ng regression, at nagpapahirap sa pagbalik kung kinakailangan.
• Pagkukulang ng pagsasama sa develop — kung ang hotfix ay hindi isinama sa develop, mawawala ang pag-aayos sa susunod na release. Matutuklasan ng team na ang parehong bug ay lumitaw muli at mapipilitang ayusin ito muli.
• Maling tag ng bersyon — ang hotfix ay dapat makatanggap ng patch increment (v2.3.0 → v2.3.1), hindi minor (v2.4.0) o major (v3.0.0). Ang paglabag sa semantic versioning ay nakakagambala sa build system at nakakalito sa mga user.
• Kawalan ng CI checks — kahit ang emergency hotfix ay dapat pumasa sa automated na mga test. Ang paglaktaw sa CI ay nagpapataas ng panganib ng pagpasok ng bagong error. Inirerekomenda na magkaroon ng hiwalay na pipeline para sa mga hotfix branch na may pinabilis na pagsusuri.

Bawat isa sa mga pagkakamaling ito ay humahantong sa pagkaantala ng paglabas ng patch o sa paglitaw ng mga bagong problema sa production. Ang mga team ay dapat magtakda ng mga patakaran para sa paggamit ng hotfix sa CONTRIBUTING.md at i-automate ang mga ito sa pamamagitan ng CI/CD checks.