Cara tim mengelola branch Git berdampak langsung pada kecepatan delivery, stabilitas production, dan friction collaboration antar developer. Dua strategi yang paling banyak diperdebatkan adalah Git Flow (model klasik dengan banyak branch) dan Trunk-Based Development (TBD, model minimalis). Artikel ini membahas keduanya secara objektif.

Git Flow: Model Klasik

Git Flow diperkenalkan Vincent Driessen pada 2010. Modelnya menggunakan beberapa branch jangka panjang:

main          — Kode production, selalu stable
develop       — Branch integrasi, tempat semua fitur di-merge
feature/*     — Branch per fitur, di-fork dari develop
release/*     — Branch persiapan release, dari develop
hotfix/*      — Perbaikan mendesak dari main

Alur Kerja Git Flow

  1. Developer fork feature/nama-fitur dari develop
  2. Kerjakan fitur, commit, push
  3. Buat PR ke develop
  4. Saat siap release, buat release/x.x.x dari develop
  5. QA di branch release, fix bug
  6. Merge ke main dan develop
  7. Tag di main

Kelebihan Git Flow

  • Cocok untuk software dengan versioning eksplisit (app yang di-install user)
  • Production (main) selalu bersih — tidak ada kode setengah jadi
  • Tim bisa mengerjakan beberapa fitur paralel tanpa saling ganggu
  • Audit trail yang jelas untuk setiap release

Kekurangan Git Flow

  • Merge conflict parah jika feature branch hidup terlalu lama
  • Overhead tinggi: banyak branch yang perlu dikelola
  • Tidak cocok untuk continuous deployment
  • Feature branch yang panjang mendorong "big bang integration"

Trunk-Based Development (TBD)

TBD adalah kebalikan filosofis dari Git Flow. Semua developer melakukan commit (atau merge) ke satu branch utama (main/trunk) sesering mungkin — idealnya beberapa kali sehari. Feature branch ada, tapi berumur sangat pendek (maksimal 1-2 hari).

main          — Satu-satunya branch jangka panjang
feature/*     — Short-lived, max 1-2 hari, lalu merge ke main

Praktik Pendukung TBD

TBD memerlukan beberapa praktik untuk bekerja efektif:

Feature Flags

Kode bisa di-commit ke main tapi belum diaktifkan untuk pengguna:

if (config('features.new_checkout_flow')) {
    return redirect()->route('checkout.new');
}
return redirect()->route('checkout.classic');

Automated Testing yang Ketat

Tanpa testing yang solid, TBD sangat berbahaya. Setiap commit ke main harus melewati CI pipeline yang lengkap (unit test, integration test, static analysis).

Branch by Abstraction

Teknik refactoring besar secara incremental tanpa feature branch panjang — ganti implementasi sedikit demi sedikit di balik abstraction layer.

Kelebihan TBD

  • Conflict lebih kecil — integrasi sering, tidak ada divergence panjang
  • Mendukung Continuous Deployment dengan baik
  • Feedback loop lebih cepat — bug terdeteksi lebih awal
  • Overhead manajemen branch minimal

Kekurangan TBD

  • Memerlukan disiplin tinggi dan test coverage yang solid
  • Feature flags menambah kompleksitas kode
  • Tidak cocok untuk software dengan release siklus panjang
  • Developer junior perlu onboarding lebih hati-hati

Rekomendasi Berdasarkan Konteks

KonteksRekomendasi
SaaS web app, deploy harianTrunk-Based Development
Mobile app dengan store review cycleGit Flow
Library / package open sourceGit Flow
Tim 1-3 developerTBD (simpler)
Tim 10+ developer, banyak fitur paralelGitHub Flow (tengah)
Regulasi ketat (fintech, kesehatan)Git Flow dengan lebih banyak gates

GitHub Flow: Jalan Tengah

Ada pilihan ketiga yang lebih simpel dari Git Flow tapi lebih terstruktur dari TBD murni:

  • main selalu deployable
  • Feature branch dari main, bukan develop
  • PR ke main dengan code review
  • Merge = deploy (atau trigger CI/CD)
  • Tidak ada branch develop, release, atau hotfix yang terpisah

GitHub Flow adalah pilihan yang solid untuk sebagian besar tim web development modern.

Tidak ada strategi branching yang universally superior. Yang paling penting: tim Anda konsisten mengikuti satu strategi yang disepakati, ada CI/CD yang mendukung, dan strategi tersebut sesuai dengan ritme delivery tim.