Git Flow, GitHub Flow, dan trunk-based: workflow Git mana yang dipilih

Apa itu Git workflow dan mengapa pilihannya penting

Git workflow adalah kesepakatan tim tentang branch apa saja yang ada, dari mana branch dibuat, ke mana digabungkan, dan apa yang dianggap siap dirilis. Git sendiri tidak memaksakan aturan apa pun. Tanpa kesepakatan, setiap orang bekerja dengan caranya sendiri; sebulan kemudian repositori penuh puluhan branch, tidak jelas mana yang sudah dirilis, dan penggabungan berubah menjadi konflik yang memakan berjam-jam.

Model yang paling dikenal adalah Git Flow, GitHub Flow (varian dari Feature Branch Workflow), dan trunk-based development. Ketiganya bukan «yang lama dan yang baru», melainkan alat untuk kondisi yang berbeda: seberapa sering Anda merilis, berapa banyak versi produk yang harus didukung sekaligus, dan seberapa matang tes otomatis Anda.

Git Flow: model dengan branch develop dan release

Git Flow dijelaskan oleh Vincent Driessen pada 2010. Model ini dibangun di atas dua branch berumur panjang:

• main (di proyek lama disebut master) — hanya berisi kode yang sudah dirilis; setiap commit di sini sesuai dengan rilis dan diberi tag;
• develop — branch integrasi tempat fitur yang sudah siap digabungkan untuk rilis berikutnya.

Ditambah tiga jenis branch sementara:

Git Flow dengan Git murni

Siklus satu fitur dan satu rilis terlihat seperti ini:

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

# rilis
git switch -c release/1.4.0 develop
# ... perbaikan versi dan bug ...
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

Flag --no-ff penting dalam model ini: ia membuat commit merge walaupun fast-forward mungkin dilakukan, sehingga di riwayat tetap terlihat commit mana yang termasuk satu fitur atau satu rilis.

Ekstensi git-flow

Agar tidak perlu mengetik rangkaian perintah tersebut satu per satu, ada utilitas git-flow (saat ini biasanya dipasang versi fork yang masih dirawat, yang di pengelola paket sering bernama git-flow-avh). Utilitas ini menambahkan subperintah:

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

git flow init menanyakan nama branch dan awalan (dengan -d nilai default dipakai), sedangkan perintah finish menjalankan semua penggabungan yang diperlukan, memberi tag, dan menghapus branch sementara. Banyak klien GUI Git juga bisa bekerja dengan Git Flow lewat tombol.

Kelebihan dan kekurangan Git Flow

Kelebihannya: struktur yang jelas, status kode yang mudah dipahami (main adalah yang dipakai pelanggan, develop adalah versi berikutnya), fase stabilisasi rilis yang terpisah, dan dukungan hotfix yang rapi. Model ini cocok untuk aplikasi mobile, perangkat lunak kemasan, pustaka, dan firmware, yaitu tempat rilis melewati peninjauan toko aplikasi atau dipasang di sisi pelanggan.

Kekurangannya: banyak branch dan penggabungan, branch fitur yang berumur panjang menumpuk perbedaan dengan develop, dan penggabungan ganda pada release dan hotfix mudah terlupakan. Untuk layanan web yang dirilis beberapa kali sehari, branch release justru menjadi birokrasi. Penulis model ini sendiri menambahkan catatan pada artikelnya di tahun 2020: untuk perangkat lunak yang dikirim secara berkelanjutan, sebaiknya pertimbangkan pendekatan yang lebih sederhana seperti GitHub Flow.

GitHub Flow: branch pendek dan pull request

GitHub Flow adalah versi ringan dari Feature Branch Workflow. Aturannya cukup beberapa poin:

1. main selalu dalam kondisi siap dan siap di-deploy.
2. Setiap pekerjaan dilakukan di branch dari main dengan nama yang jelas.
3. Branch sering di-push dan dibuka pull request (merge request) untuk didiskusikan.
4. Setelah review dan CI hijau, branch digabung ke main.
5. Apa pun yang digabung ke main langsung di-deploy.

git switch main
git pull
git switch -c feature/new-payment
# ... commit dengan pesan yang jelas ...
git push -u origin feature/new-payment
# buka pull request, lewati review dan CI, gabung ke main

Kelebihannya: satu branch berumur panjang, aturan minimal, jalur cepat dari ide sampai produksi, dan code review yang terintegrasi. Kekurangannya: tidak ada tempat khusus untuk mendukung beberapa versi sekaligus atau menstabilkan rilis, dan tanpa tes otomatis yang baik, «main selalu siap» hanya tinggal harapan.

Pendekatan serupa dengan tambahan branch lingkungan (misalnya staging dan production) kadang disebut GitLab Flow. Ini berguna ketika deploy ke produksi tidak langsung dilakukan, melainkan terjadwal atau setelah pemeriksaan manual.

Trunk-based development

Dalam trunk-based development, semua pengembang mengintegrasikan perubahan ke satu branch (trunk, yaitu main) dengan sering, minimal sekali sehari. Branch jika ada hanya hidup berjam-jam, bukan berminggu-minggu. Fitur yang belum selesai boleh masuk ke main, tetapi disembunyikan di balik feature flag:

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

Keunggulan utamanya: hampir tidak ada konflik besar, karena perubahannya kecil dan langsung digabung selagi semua orang masih ingat konteksnya. Model ini mendukung integrasi berkelanjutan dalam arti harfiah dan cocok untuk tim matang dengan CI yang cepat serta cakupan tes yang tinggi. Branch rilis tetap diperbolehkan, tetapi dibuat dari trunk tepat sebelum rilis, dan perbaikan dilakukan lebih dulu di trunk lalu dipindahkan dengan cherry-pick.

Kekurangannya: dibutuhkan disiplin dan infrastruktur, yaitu tes yang cepat, flag, dan pemantauan. Pemula mungkin takut commit ke main setiap hari, dan CI yang lemah membuat trunk selalu rusak. Flag juga harus segera dihapus setelah tidak dipakai, kalau tidak kode akan penuh cabang mati.

Perbandingan Git Flow, GitHub Flow, dan trunk-based

Cara memilih git workflow untuk tim

Jawab beberapa pertanyaan berikut:

• Apakah perlu mendukung beberapa versi yang sudah dirilis? Jika pelanggan masih memakai 2.x dan 3.x dan keduanya butuh perbaikan, pilih Git Flow atau trunk-based dengan branch rilis.
• Seberapa sering Anda melakukan deploy? Sekali per kuartal — Git Flow tidak akan mengganggu. Setiap hari — pilih GitHub Flow atau trunk-based.
• Seberapa besar kepercayaan Anda pada tes? Jika CI lambat dan cakupan tes lemah, mulailah dengan GitHub Flow yang mewajibkan review, lalu perlahan persingkat branch.
• Seberapa besar dan berpengalaman timnya? Untuk tim kecil dan anggota baru, GitHub Flow paling sederhana: satu aturan «main selalu bekerja» dan pull request untuk semua perubahan.

Saran praktis: jangan memilih Git Flow hanya karena itu «sudah lazim». Mulailah dari proses paling sederhana yang menyelesaikan masalah Anda, dan tambahkan kerumitan hanya ketika muncul kebutuhan nyata, misalnya perlu fase stabilisasi atau dukungan untuk versi lama.

Aturan yang berlaku di workflow apa pun

• Lindungi main di server: larang push langsung, wajibkan review dan CI hijau sebelum penggabungan.
• Sepakati nama branch: feature/, fix/, hotfix/ ditambah nomor tugas.
• Jaga branch tetap pendek: makin lama branch hidup, makin sulit digabungkan. Rutin masukkan main terbaru ke branch Anda lewat merge atau rebase.
• Pilih satu strategi penggabungan pull request (merge commit, squash, atau rebase) dan gunakan secara konsisten.
• Beri tag rilis dengan tag beranotasi berdasarkan penomoran semantik.

Hotfix di setiap model: satu bug, tiga proses

Perbedaan antar-pendekatan paling jelas terlihat pada perbaikan darurat di produksi.

Di Git Flow, dibuat branch hotfix/1.4.1 dari main. Setelah diperbaiki, branch digabung ke main dengan tag v1.4.1 dan wajib juga ke develop (atau ke branch rilis yang sedang aktif). Lupa melakukan penggabungan kedua adalah kesalahan klasik: di rilis berikutnya bug itu «muncul kembali».

git switch -c hotfix/1.4.1 main
git commit -am "Perbaiki perhitungan diskon"
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

Di GitHub Flow, hotfix adalah branch pendek biasa dari main dengan pull request yang diberi prioritas dalam review. Setelah digabung, perubahan langsung dikirim ke produksi lewat deploy otomatis yang sama, tanpa proses terpisah.

Di trunk-based, perbaikan lebih dulu di-commit ke trunk. Jika di produksi ada branch rilis yang berjalan, commit itu dipindahkan ke sana dengan git cherry-pick -x <hash>. Flag -x menambahkan tautan ke commit asal di pesan, sehingga hubungannya tetap terlihat di riwayat. Jika masalahnya ada pada fitur baru, sering kali cukup mematikan feature flag-nya tanpa menyentuh kode sama sekali.

Menjawab di wawancara «workflow Git apa yang Anda pakai»

Pewawancara tidak sedang menguji hafalan nama, melainkan pemahaman tentang kompromi. Jawaban yang baik menyebutkan modelnya, menjelaskan bagaimana branch dan review bekerja di dalamnya, dan menerangkan mengapa model itu cocok untuk proyek tersebut. Misalnya: «Kami memakai GitHub Flow: branch dari main, pull request dengan review wajib dan CI, lalu deploy otomatis setelah penggabungan. Kami tidak memakai Git Flow karena merilis beberapa kali seminggu dan branch release hanya akan memperlambat.» Nilai tambahnya adalah menjelaskan apa yang akan Anda ubah seandainya proses itu tumbuh.

Ringkasan

Git Flow adalah model ketat dengan branch develop, release, dan hotfix, cocok untuk produk dengan versi terjadwal dan dukungan beberapa rilis. GitHub Flow lebih sederhana dan cocok untuk sebagian besar proyek web, sedangkan trunk-based development memberi kecepatan maksimal tetapi menuntut CI yang matang dan feature flag. Pilih workflow berdasarkan frekuensi rilis dan kualitas tes, bukan karena tren. Ketiga pendekatan beserta perintah dan kesalahan umumnya dibahas dengan praktik dalam kursus Git.