Belajar Git Branching Strategies - GitFlow Workflow (Vincent Driessen)

#Pendahuluan

Setelah di episode 5 kita memahami Pull Request & Code Review — PR sebagai gerbang kualitas, branch protection, dan tiga merge strategy — pada episode ini kita masuk ke GitFlow Workflow, salah satu branching strategy paling terstruktur yang pernah dibuat. GitFlow dikembangkan oleh Vincent Driessen pada 2010 dan menjadi standar de facto untuk produk dengan release berkala.

GitFlow menjawab pertanyaan yang belum dijawab oleh feature branch workflow sederhana: bagaimana mengelola multiple release channels, hotfix untuk production, dan persiapan release secara terstruktur.

#Arsitektur GitFlow

GitFlow memiliki lima jenis branch dengan peran masing-masing:

#Branch Persisten (2)

main (atau master): Branch production. Hanya berisi kode yang sudah di-deploy dan teruji.
develop: Branch integrasi. Semua fitur baru di-merge ke sini untuk persiapan rilis berikutnya.

#Branch Temporer (3)

feature/*: Branch fitur. Lahir dari develop, merge kembali ke develop.
release/*: Branch persiapan rilis. Lahir dari develop, merge ke main + develop.
hotfix/*: Perbaikan darurat production. Lahir dari main, merge ke main + develop.

100%

#Alur Merge Lengkap

Branch Asal	Branch Tujuan	Kapan
`feature/*`	`develop`	Setelah fitur selesai & di-review
`release/*`	`main` + `develop`	Saat release final
`hotfix/*`	`main` + `develop`	Saat perbaikan darurat production

100%

#Kelebihan GitFlow

#Sangat Terstruktur

GitFlow memberikan jawaban yang jelas untuk setiap skenario:

Fitur baru? → feature/* dari develop.
Persiapan rilis? → release/* dari develop.
Bug production? → hotfix/* dari main.
Eksperimen? → feature/* yang tidak di-merge jika gagal.

#Hotfix Terisolasi

Hotfix branch lahir langsung dari main — tidak perlu menunggu develop atau fitur lain selesai. Ini memastikan perbaikan darurat bisa di-deploy secepat mungkin.

#Kekurangan GitFlow

#Terlalu Kompleks untuk Continuous Delivery

Jika produk kalian di-deploy setiap commit ke main, GitFlow terlalu berat. Lima jenis branch dengan alur merge yang berbeda menambah overhead yang tidak perlu untuk tim yang ingin continuous delivery.

#Banyak Branch Hidup Bersamaan

Saat sprint aktif, kalian bisa memiliki 5-10 branch feature/*, 1-2 branch release/*, dan mungkin 1 hotfix/* secara bersamaan. Ini meningkatkan resiko konflik dan membuat graf commit sulit dibaca.

#Kapan Menggunakan GitFlow

Kondisi	Gunakan GitFlow?
Produk dengan rilis berkala (bulanan/quarterly)	Ya
Tim besar dengan role terpisah	Ya
SaaS dengan continuous delivery	Tidak — GitHub Flow lebih cocok
Tim kecil (2-5 developer)	Kurang cocok — terlalu banyak branch

Note

GitFlow bukan approach yang salah — ia hanya untuk konteks yang tepat. Banyak produk enterprise dengan release quarterly yang sangat sukses menggunakan GitFlow. Yang salah adalah menggunakan GitFlow untuk produk yang ingin continuous deployment setiap commit.

#Penutup

Pada episode 6 ini, kalian telah memahami GitFlow Workflow:

Lima jenis branch: main, develop, feature/*, release/*, hotfix/*.
Alur merge terstruktur: feature ke develop, release ke main + develop, hotfix ke main + develop.
Kelebihan: sangat terstruktur, hotfix terisolasi, cocok untuk produk multi-versi.
Kekurangan: kompleks untuk continuous delivery, banyak branch hidup bersamaan.
Gunakan untuk produk dengan rilis berkala dan tim besar.

Di episode 7 selanjutnya kita akan mempelajari GitHub Flow — pendekatan yang jauh lebih sederhana dengan hanya satu branch persisten, di mana semua perubahan via Pull Request dan deploy dilakukan dari main. Sampai jumpa di episode 7!