Hotfix branch pattern untuk perbaikan darurat production: branch lahir dari main, fix langsung, merge ke main dan develop, best practice untuk hotfix yang sangat pendek-lived, serta perbedaan hotfix vs feature branch yang menentukan kapan menggunakan jalur mana.

Setelah di episode 9 kita mempelajari Release Management — SemVer, tags, dan changelog otomatis — pada episode ini kita membahas skenario yang paling menegangkan: production bug. Ketika user melaporkan crash atau vulnerability di production, kalian tidak punya waktu untuk menunggu sprint berikutnya. Dibutuhkan hotfix — perbaikan darurat yang di-deploy sesegera mungkin.
Hotfix workflow memastikan perbaikan darurat terisolasi, teruji, dan di-deploy tanpa mengganggu development cycle yang sedang berjalan.
Hotfix branch lahir langsung dari main (atau production), bukan dari develop:
# 1. Buat hotfix branch dari main
git switch main
git checkout -b hotfix/critical-login-bug
# 2. Fix dan commit
git add .
git commit -m "fix: perbaiki race condition di login handler"
# 3. Merge ke main
git switch main
git merge --no-ff hotfix/critical-login-bug -m "Merge hotfix/critical-login-bug"
# 4. Tag versi patch
git tag -a v1.2.1 -m "Hotfix: perbaiki race condition login"
# 5. Merge ke develop
git switch develop
git merge --no-ff hotfix/critical-login-bug -m "Merge hotfix ke develop"
# 6. Hapus branch hotfix
git branch -d hotfix/critical-login-bugHotfix branch harus hidup beberapa jam saja — bukan hari. Jika hotfix membutuhkan waktu berminggu-minggu, itu bukan hotfix, itu fitur baru yang harus menggunakan feature branch.
Meskipun terburu-buru, tests harus passing sebelum merge. Bug fix yang memecahkan fitur lain lebih buruk dari bug asli. Minimal jalankan test suite yang relevan.
Update changelog dan release notes. User dan tim perlu tahu apa yang diperbaikan, mengapa, dan versi patch apa yang harus di-deploy.
| Aspek | Hotfix | Feature Branch |
|---|---|---|
| Tujuan | Bug di production yang mempengaruhi user | Bug ditemukan di development, belum di-deploy |
| Branch dari | main / production | main / develop |
| Durasi | Beberapa jam | Beberapa hari |
| Deploy | Segera ke production | Setelah sprint/release berikutnya |
Warning
Jangan gunakan hotfix untuk bug yang hanya muncul di development. Hotfix adalah jalur darurat — gunakan hanya saat production user terdampak. Penyalahgunaan hotfix akan menghancurkan workflow tim.
Pada episode 10 ini, kalian telah memahami Hotfix Workflow:
main/production, bukan develop.main + develop → tag → hapus branch.Di episode 11 selanjutnya kita akan mempelajari Cherry-Picking & Selective Merge — cara mengambil commit tertentu dari satu branch dan menerapkannya ke branch lain tanpa merge seluruh branch. Sampai jumpa di episode 11!