Trunk-Based Development

GitFlow menutup bab sebelumnya dengan lima jenis branch dan protokol rilis lengkap. Trunk-Based Development berdiri di ujung spektrum yang berlawanan: hampir seluruh upacara dibuang, dan semua orang diminta berkomit langsung — sering, dalam potongan kecil — ke satu jalur bernama trunk, yaitu main kita. Masalah yang dijawab tetap integrasi: semakin lama pekerjaan terpisah dari jalur utama, semakin jauh dunia bergerak tanpanya, dan semakin menyakitkan penyatuannya. Trunk-Based Development menyerang akarnya — jangan biarkan pekerjaan terpisah lama.

Filosofi: Satu Rumah untuk Semua Commit #

Aturannya diringkas dua kalimat. Pertama, semua commit menuju main — langsung, atau lewat branch yang hidup sangat singkat. Kedua, branch berumur kurang dari sehari — sering hanya berjam-jam. Praktisinya berusaha menyatu ke trunk sedikitnya sekali sehari, sehingga tidak ada pekerjaan yang menggantung terpisah lebih dari dua puluh empat jam.

Konsekuensinya: main tidak boleh pernah sakit. Pada GitHub Flow , cabang yang belum siap menunggu di branch sebelum menyatu; di sini hampir tidak ada tempat menunggu. Fitur yang belum selesai pun harus masuk ke trunk tanpa mengganggu — dan untuk itu ada feature flag.

Tiga Kebiasaan Penopang #

Commit kecil — satu commit membawa satu perubahan logis yang dijelaskan sebaris pesan. Potongan kecil membuat review singkat, git bisect cepat menemukan pelaku kerusakan, dan revert tidak menggondol pekerjaan lain.
Feature flag — fitur baru dikirim dalam keadaan mati: kode hadir di trunk, efeknya dinyalakan lewat konfigurasi. Pekerjaan setengah jadi menyatu tanpa dilihat pengguna; pengaktifannya cukup satu commit kecil.
Review pra-merge — karena gerbang merge panjang hilang, telaah bergeser ke sebelum menyatu: pair programming saat menulis, atau pull request kecil yang selesai dalam hitungan jam.

Trunk-Based vs Feature Branch #

Perbandingannya paling jujur bila diadu langsung dengan Feature Branch Workflow — panggungnya sama, disiplinnya yang beda:

Aspek	Feature Branch	Trunk-Based
Ukuran integrasi	satu fitur utuh, boleh besar	potongan kecil, beberapa per hari
Usia branch	hari hingga minggu	kurang dari sehari, sering menit
Risiko konflik	tumbuh seiring usia branch	nyaris nol karena selisih selalu kecil
Cocok untuk	tim dengan review formal dan ritme rilis	tim dengan CI matang dan deploy kontinu

Tabel ini bukan vonis bahwa feature branch salah — ia pertukaran. Feature branch menumpuk risiko ke “minggu integrasi” di ujung; Trunk-Based Development memindahkan tuntutan ke disiplin harian: trunk harus selalu hijau di CI , dan tiap potongan cukup kecil untuk ditelaah cepat seperti dilatih di Code Review .

Demo: Satu Pagi di Trunk #

Budi membangun toko, Siti ikut bekerja, dan seluruh fitur keranjang — dari branch sampai pengaktifan — selesai dalam satu pagi. Variabel GIT_AUTHOR_DATE/GIT_COMMITTER_DATE hanya menambat tanggal supaya jam di git log konsisten; git commit biasa sudah cukup.

Hari dibuka tiga commit serial — masing-masing satu berkas, semuanya langsung ke main:

bash
mkdir budi && cd budi
git init -b main
git config user.name "Budi Santoso"
git config user.email "[email protected]"
printf 'beranda\n' > situs.md
git add situs.md
GIT_AUTHOR_DATE="2026-10-20T09:00:00+07:00" GIT_COMMITTER_DATE="2026-10-20T09:00:00+07:00" \
  git commit -m "Tambah beranda"
printf 'tentang\n' > tentang.md
git add tentang.md
GIT_AUTHOR_DATE="2026-10-20T09:20:00+07:00" GIT_COMMITTER_DATE="2026-10-20T09:20:00+07:00" \
  git commit -m "Tambah halaman tentang"
printf 'kontak\n' > kontak.md
git add kontak.md
GIT_AUTHOR_DATE="2026-10-20T09:40:00+07:00" GIT_COMMITTER_DATE="2026-10-20T09:40:00+07:00" \
  git commit -m "Tambah halaman kontak"

Output yang Dihasilkan (perintah terakhir):

text
[main b318294] Tambah halaman kontak
 1 file changed, 1 insertion(+)
 create mode 100644 kontak.md

Belum ada satu pun branch. Repo bersama disiapkan, lalu kerja hari itu mulai bergerak:

bash
git init --bare ../toko-tbd.git
git remote add origin ../toko-tbd.git
git push -u origin main

Output yang Dihasilkan (perintah terakhir):

text
To ../toko-tbd.git
 * [new branch]      main -> main
branch 'main' set up to track 'origin/main'.

Inilah latihan pertama feature flag: commit pertama fitur keranjang bukan keranjangnya, melainkan kuncinya, dikirim dalam keadaan nonaktif:

bash
printf 'keranjang=nonaktif\n' > fitur.ini
git add fitur.ini
GIT_AUTHOR_DATE="2026-10-20T10:00:00+07:00" GIT_COMMITTER_DATE="2026-10-20T10:00:00+07:00" \
  git commit -m "Kunci keranjang di balik flag"
git push origin main

Output yang Dihasilkan (dua perintah terakhir):

text
[main dd5edc1] Kunci keranjang di balik flag
 1 file changed, 1 insertion(+)
 create mode 100644 fitur.ini

text

To ../toko-tbd.git
   b318294..dd5edc1  main -> main

Sementara itu Siti menaruh mejanya — dan langsung menyumbang satu commit kecil ke trunk:

bash
cd ..
git clone toko-tbd.git siti
cd siti
git config user.name "Siti Rahma"
git config user.email "[email protected]"
printf 'toko budi\n' > footer.md
git add footer.md
GIT_AUTHOR_DATE="2026-10-20T10:25:00+07:00" GIT_COMMITTER_DATE="2026-10-20T10:25:00+07:00" \
  git commit -m "Tambah footer"
git push origin main

Output yang Dihasilkan (dua perintah terakhir):

text
[main 87e29df] Tambah footer
 1 file changed, 1 insertion(+)
 create mode 100644 footer.md

text

To ../toko-tbd.git
   dd5edc1..87e29df  main -> main

Trunk bergerak — itu justru inti kerjanya. Kini satu-satunya branch hari ini, yang hidupnya memang singkat: kode keranjang ditulis di balik flag yang tadi dikunci:

bash
cd ../budi
git switch -c fitur/keranjang
printf 'keranjang\n' > keranjang.md
git add keranjang.md
GIT_AUTHOR_DATE="2026-10-20T10:20:00+07:00" GIT_COMMITTER_DATE="2026-10-20T10:20:00+07:00" \
  git commit -m "Tambah keranjang di balik flag"

Output yang Dihasilkan (perintah terakhir):

text
[fitur/keranjang c29fa9b] Tambah keranjang di balik flag
 1 file changed, 1 insertion(+)
 create mode 100644 keranjang.md

Menyatu menuntut dua gerakan: tarik yang terbaru — Siti sudah menambah footer — lalu gabungkan:

bash
git switch main
git pull
GIT_AUTHOR_DATE="2026-10-20T10:30:00+07:00" GIT_COMMITTER_DATE="2026-10-20T10:30:00+07:00" \
  git merge fitur/keranjang
git branch -d fitur/keranjang

Output yang Dihasilkan (dua perintah terakhir):

text
Merge made by the 'ort' strategy.
 keranjang.md | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 keranjang.md

text

Deleted branch fitur/keranjang (was c29fa9b).

Karena main sudah maju, Git menjalankan merge tiga arah sungguhan — bukan maju cepat — mekanisme yang dibedah di Three-Way Merge . Terakhir, fitur dinyalakan satu commit kecil:

bash
printf 'keranjang=aktif\n' > fitur.ini
git add fitur.ini
GIT_AUTHOR_DATE="2026-10-20T10:35:00+07:00" GIT_COMMITTER_DATE="2026-10-20T10:35:00+07:00" \
  git commit -m "Aktifkan fitur keranjang"
git push origin main

Output yang Dihasilkan (dua perintah terakhir):

text

[main 68b63b0] Aktifkan fitur keranjang
 1 file changed, 1 insertion(+), 1 deletion(-)

text

To ../toko-tbd.git
   87e29df..68b63b0  main -> main

Riwayat akhirnya ramping — hanya satu gelembung merge sehari:

bash

git log --oneline --graph --decorate --all

Output yang Dihasilkan:

text
* 68b63b0 (HEAD -> main, origin/main) Aktifkan fitur keranjang
*   29d6269 Merge branch 'fitur/keranjang'
|\  
| * c29fa9b Tambah keranjang di balik flag
* | 87e29df Tambah footer
|/  
* dd5edc1 Kunci keranjang di balik flag
* b318294 Tambah halaman kontak
* 2bbfd77 Tambah halaman tentang
* 24dd903 Tambah beranda

Waktunya terbaca langsung dari riwayat:

bash
git log --format='%ad %s' --date=format:'%H:%M'

Output yang Dihasilkan:

text
35 Aktifkan fitur keranjang
30 Merge branch 'fitur/keranjang'
25 Tambah footer
20 Tambah keranjang di balik flag
00 Kunci keranjang di balik flag
40 Tambah halaman kontak
20 Tambah halaman tentang
00 Tambah beranda

Hash di mesin pembaca berbeda; ritmenya tidak. Seluruh siklus fitur keranjang — kunci, kode, merge, aktifkan — berlangsung tiga puluh lima menit; branch-nya hidup sepuluh menit, lahir jam 10:20 dan terhapus jam 10:30. Itulah “kurang dari sehari” dalam praktik.

Kapan Trunk-Based Cocok — dan Kapan Tidak #

Situasi	Kecocokan	Alasan
Web / SaaS dengan deploy berkali sehari	sangat cocok	jarak commit-ke-produksi memang satu langkah
Tim dengan CI dan tes otomatis menyeluruh	sangat cocok	jaring pengaman menampung commit langsung yang keliru
Tim kecil senior berdisiplin tinggi	cocok	koordinasi sosial lebih ringan daripada protokol
CI lemah atau tes masih manual	tidak cocok	trunk rusak tidak ketahuan sampai merusak semua orang
Review wajib dan lambat secara formal	tidak cocok	antrean review melahirkan branch berumur panjang
Rilis bernomor versi terjadwal	kurang	butuh branch pembekuan — wilayah GitFlow

Prasyaratnya memang tinggi: tes otomatis yang lekas menangkap kerusakan, dan budaya menulis potongan kecil. Panduan lengkap dari komunitas praktisinya — termasuk pola stacked pull request dan peta feature flag — dirangkum di trunkbaseddevelopment.com .

Trunk yang sehat bergerak cepat — semua orang commit ke situ berkali sehari. Konsekuensinya, branch yang hidup lebih lama dari beberapa jam mulai tertinggal, dan selisihnya tumbuh diam-diam. Chapter berikutnya melatih disiplin menghadapinya: mengecek seberapa jauh tertinggal, lalu menyatu kembali lewat merge atau rebase.