Belajar Git Branching Strategies - Trunk-Based Development (TBD)

#Pendahuluan

Setelah di episode 2 kita memahami konsep dasar branching — pointer ringan, merge vs rebase, fast-forward vs non-fast-forward — pada episode ini kita masuk ke branching strategy pertama: Trunk-Based Development (TBD). TBD adalah salah satu pendekatan paling populer di era CI/CD modern, dan menjadi fondasi bagi Continuous Integration sesungguhnya.

TBD bukan tentang menghapus branch sepenuhnya — tetapi tentang membuat branch yang sangat pendek-lived dan mengintegrasikan kode ke trunk (branch utama) sesering mungkin.

#Filosofi Trunk-Based Development

Prinsip inti TBD:

1. Satu branch utama (main atau trunk) — semua developer push ke sana secara sering.
2. Branch sangat pendek-lived — hidup beberapa jam, bukan hari atau minggu.
3. Feature flags menggantikan long-lived branches — kode baru di-deploy tetapi dinonaktifkan sampai siap.

Perhatikan: feature/quick hanya hidup untuk 1 commit (C), dan feature/short hanya untuk 1 commit (E). Ini adalah ideal TBD — branch hidup sangat singkat, di-merge secepat mungkin ke main.

#Feature Flags: Replace Long-Lived Branches

Bayangkan fitur baru yang membutuhkan waktu berminggu-minggu. Di TBD, kalian tidak membuat branch hidup selama berminggu-minggu. Sebaliknya, kalian mengaktifkan kode secara bertahap di main dan menggunakan feature flag untuk mengontrol visibilitas:

if (featureFlags.isEnabled('new-checkout-flow')) {
  return newCheckoutHandler(request)
}
return legacyCheckoutHandler(request)

Kode baru di-deploy ke production tetapi tidak terlihat oleh user sampai flag diaktifkan. Ini memungkinkan integrasi berkelanjutan tanpa risiko.

#Keunggulan TBD

#Mengurangi Merge Conflict

Karena semua developer bekerja dalam branch pendek yang sering di-merge, perubahan kecil dan frequent mengurangi kemungkinan konflik besar. Konflik kecil (1-2 file) jauh lebih mudah diselesaikan daripada konflik ratusan baris dari branch yang hidup berminggu-minggu.

#CI/CD Lebih Sederhana

Dengan satu branch utama untuk di-deploy, pipeline menjadi sederhana: push ke main → test → deploy. Tidak ada branch develop, release, atau staging yang perlu dikelola secara manual.

#Continuous Integration Sesungguhnya

TBD adalah implementasi paling murni dari Continuous Integration: semua developer mengintegrasikan kode ke trunk setidaknya sekali sehari. Ini mengurangi "integration hell" yang terjadi saat branch hidup terlalu lama.

#Kapan TBD Cocok Digunakan

#Contoh Praktik TBD

# 1. Sync dengan main terbaru
git switch main && git pull origin main
 
# 2. Buat branch pendek
git switch -c feature/add-search-api
 
# 3. Kerja, commit kecil-kecil
git add . && git commit -m "feat: add search endpoint"
git add . && git commit -m "feat: add search validation"
 
# 4. Push dan buka PR
git push -u origin feature/add-search-api
 
# 5. Setelah PR di-merge, hapus branch
git switch main && git pull origin main
git branch -d feature/add-search-api

Perhatikan: branch hidup untuk beberapa commit saja, lalu dihapus setelah merge. Ini adalah ritme TBD yang sehat.

#Penutup

Pada episode 3 ini, kalian telah memahami Trunk-Based Development:

• Satu branch utama, feature branch sangat pendek-lived (jam, bukan hari).
• Feature flags menggantikan long-lived branches — kode di-deploy tetapi disembunyikan.
• Keunggulan: mengurangi merge conflict, CI/CD sederhana, continuous integration sesungguhnya.
• Cocok untuk tim kecil-menengah dengan rilis frekuens tinggi dan feature flags system.

Di episode 4 selanjutnya kita akan mempelajari Feature Branch Workflow — pendekatan paling umum di mana setiap fitur dibuat di branch terpisah dari main, dengan naming convention dan alur kerja lengkap. Sampai jumpa di episode 4!