Git Flow vs Trunk-Based Development: Mana yang Cocok untuk Tim Kamu?

Git Flow dan trunk-based development adalah dua strategi branching dengan filosofi berlawanan. Git Flow memakai banyak branch berumur panjang (main, develop, feature, release, hotfix) dan cocok untuk produk dengan rilis terjadwal. Trunk-based development menggabungkan perubahan kecil ke satu branch utama setiap hari dan cocok untuk tim yang merilis sering dengan CI yang kuat. Pilihannya bergantung pada frekuensi rilis, ukuran tim, dan kematangan test otomatis.

Git Flow

main      ●────────────●────────────●      (rilis produksi)
           \          / \          /
release     \    ●───●   \    ●───●
             \  /         \  /
develop  ●────●──●──●──●───●──●──●──●
              \     /   \      /
feature        ●───●     ●────●

• main: hanya kode yang sudah dirilis.
• develop: tempat integrasi fitur untuk rilis berikutnya.
• feature/*: satu branch per fitur, dibuat dari develop.
• release/*: persiapan rilis, hanya perbaikan bug.
• hotfix/*: perbaikan darurat dari main.

Kelebihan: struktur jelas, cocok untuk banyak versi yang dirawat bersamaan (misalnya aplikasi desktop atau mobile dengan versi 2.x dan 3.x), dan rilis bisa diuji di branch khusus.

Kekurangan: feature branch yang berumur berminggu-minggu menimbulkan konflik merge besar, integrasi terlambat, dan alur yang terasa berat untuk aplikasi web yang bisa dirilis kapan saja.

Trunk-Based Development

main  ●──●──●──●──●──●──●──●──●──●   (selalu bisa dirilis)
       \/    \/     \/    \/
      short-lived branch (jam sampai 1-2 hari)

• Semua developer menggabungkan perubahan kecil ke main paling lambat sehari atau dua hari sekali.
• Branch pendek dipakai untuk pull request dan review, lalu dihapus.
• Fitur yang belum selesai disembunyikan dengan feature flag, bukan ditahan di branch.
• Setiap commit di main harus lulus test otomatis dan siap rilis.

Kelebihan: konflik kecil karena integrasi terus-menerus, umpan balik cepat, dan cocok dengan continuous delivery.

Kekurangan: butuh disiplin, test otomatis yang andal, CI cepat, dan kebiasaan memecah pekerjaan menjadi perubahan kecil.

Perbandingan Git Flow dan Trunk-Based Development

Cara Memilih

• Tim kecil, aplikasi web, belum banyak test: mulai dengan alur sederhana ala GitHub Flow, yaitu main ditambah feature branch pendek dan pull request. Sambil berjalan, tambah test dan perpendek umur branch.
• Aplikasi mobile dengan rilis lewat app store: Git Flow atau variasinya masuk akal karena rilis memang terjadwal dan versi lama perlu hotfix.
• Tim SaaS dengan CI matang: trunk-based development memberi kecepatan tertinggi.
• Proyek klien dengan tahap UAT: tambahkan branch atau environment staging untuk pengujian klien, tanpa harus memakai seluruh Git Flow.

Feature Flag Sederhana di Laravel

Laravel Pennant menyediakan feature flag resmi:

Feature::define('laporan-baru', fn (User $user) => $user->isInternal());

// di controller atau Blade
if (Feature::active('laporan-baru')) {
    return view('reports.new');
}

Dengan flag, kode fitur yang belum selesai bisa digabung ke main lebih awal tanpa terlihat oleh pengguna.

Aturan yang Berlaku untuk Keduanya

• Pull request kecil lebih cepat ditinjau dan lebih jarang menyimpan bug.
• Pesan commit yang jelas: apa yang berubah dan kenapa.
• Lindungi branch utama: wajib review dan CI hijau sebelum merge.
• Hapus branch setelah merge agar repositori tetap rapi.

Kesalahan yang Sering Terjadi

• Memakai Git Flow penuh untuk aplikasi web kecil, sehingga merilis satu perbaikan kecil butuh beberapa langkah merge.
• "Trunk-based" tanpa test. Menggabungkan langsung ke main tanpa CI berarti production sering rusak.
• Feature flag yang tidak pernah dihapus, sehingga kode dipenuhi percabangan mati.
• Branch fitur berbulan-bulan, apa pun strateginya.

Langkah Berikutnya

Kalau perintah dasar Git seperti branch, merge, dan rebase belum lancar, mulai dari Git untuk pemula. Untuk tim yang memakai AI agent dalam coding, alur branch yang rapi makin penting; lihat agentic AI coding.