Git Workflow untuk Tim yang Ingin Tetap Waras: Trunk-Based vs Gitflow

Git Workflow untuk Tim yang Ingin Tetap Waras: Trunk-Based vs Gitflow

Ada dua tanda tim developer sedang tidak baik-baik saja dengan Git mereka: pertama, merge conflict yang muncul setiap sprint dan memakan waktu berjam-jam. Kedua, takut merge ke main karena tidak tahu apa yang akan rusak. Kedua masalah ini hampir selalu bisa ditelusuri ke satu sumber: workflow Git yang tidak cocok dengan ritme kerja tim.

Artikel ini membahas dua pendekatan paling umum — Gitflow dan Trunk-Based Development — dan kapan masing-masing masuk akal.

---

Gitflow: Terstruktur, tapi Bisa Jadi Beban

Gitflow dipopulerkan Vincent Driessen pada 2010 dan sempat menjadi standar de facto. Strukturnya:

• main — hanya berisi kode yang sudah release ke production.
• develop — integrasi semua fitur yang sedang dikerjakan.
• feature/* — branch per fitur, dibuat dari develop.
• release/* — persiapan release, testing akhir.
• hotfix/* — perbaikan darurat langsung dari main.

Kelebihannya jelas: setiap tahap punya jalur yang terdefinisi. Release terkontrol. History bersih jika diikuti dengan benar.

Masalahnya muncul ketika tim mulai bergerak cepat:

• Branch fitur hidup terlalu lama → merge conflict besar saat akhirnya digabung.
• develop sering dalam kondisi "setengah jadi" yang tidak bisa langsung di-deploy.
• Proses release memerlukan beberapa branch sekaligus, membingungkan anggota tim baru.
• Hotfix harus di-merge ke dua tempat sekaligus (main dan develop) — mudah terlewat.

Bahkan Vincent Driessen sendiri menambahkan catatan di artikel aslinya: untuk aplikasi web modern yang continuous delivery, Gitflow mungkin bukan pilihan yang tepat.

Trunk-Based Development: Sederhana, tapi Butuh Disiplin

Trunk-Based Development (TBD) punya premis yang berbeda: semua developer merge ke satu branch utama (main atau trunk) sesering mungkin — idealnya setiap hari. Branch fitur boleh ada, tapi umurnya pendek: maksimal 1-2 hari sebelum digabung.

# Alur khas Trunk-Based Development
git checkout -b feature/tambah-endpoint-user
# ... kerja, commit kecil-kecil ...
# selesai dalam 1 hari
git push origin feature/tambah-endpoint-user
# buka PR, review cepat, merge hari ini juga

Yang membuat ini bisa bekerja:

• Feature flags: kode fitur yang belum siap tetap bisa di-merge tapi dimatikan via flag. Deploy dan release dipisahkan.
• Test otomatis yang cepat: CI harus memberi feedback dalam menit, bukan jam.
• Review culture yang tidak blocker: PR tidak menunggu berhari-hari untuk di-review.

Kelebihannya: merge conflict jarang terjadi karena integrasi sering. Main selalu dalam kondisi deployable. Feedback dari integrasi cepat terasa.

Perbandingan Praktis

Aspek	Gitflow	Trunk-Based
Kompleksitas workflow	Tinggi	Rendah
Frekuensi merge conflict	Tinggi (branch lama)	Rendah (merge sering)
Cocok untuk	Software dengan versioning ketat (mobile app, library)	Web app, SaaS, continuous delivery
Kebutuhan CI/CD	Fleksibel	Wajib kuat
Feature flags	Opsional	Sangat dianjurkan

Hal yang Lebih Penting dari Pilihan Workflow

Apapun workflow yang dipilih, ada beberapa praktik yang lebih menentukan kesehatan kolaborasi Git di tim:

Commit yang Bermakna

Commit message "fix bug" atau "update" tidak membantu siapapun, termasuk diri sendiri 3 bulan ke depan. Format Conventional Commits membantu:

feat(auth): tambah refresh token rotation
fix(payment): handle edge case saldo negatif
chore(deps): update library ke versi terbaru

PR yang Kecil dan Fokus

PR dengan 50 file berubah hampir tidak mungkin di-review dengan baik. PR yang bagus punya satu tujuan, bisa di-review dalam 15 menit, dan tidak mengubah hal yang tidak perlu diubah. Ini lebih berpengaruh pada kecepatan tim daripada pilihan workflow apapun.

Branch Protection yang Konsisten

Pastikan main terlindungi: wajib CI hijau sebelum merge, minimal satu approval, tidak boleh force push. Ini bukan birokratis — ini fondasi yang mencegah masalah yang susah di-debug nanti.

Rekomendasi untuk Tim Baru

Jika tim baru memulai dan belum punya workflow established, mulailah dengan yang lebih sederhana:

1. Gunakan GitHub Flow (bukan Gitflow): branch dari main, buka PR, merge setelah review dan CI hijau.
2. Jaga branch tetap pendek. Jika fitur besar, pecah menjadi PR kecil yang bisa di-merge secara incremental.
3. Investasi di test otomatis lebih awal. Ini yang membuat merge ke main terasa aman.
4. Evaluasi ulang saat tim dan codebase berkembang — bukan sekarang.

Kesimpulan

Tidak ada workflow Git yang universal terbaik. Gitflow masuk akal untuk produk dengan siklus release yang terdefinisi jelas. Trunk-Based Development bekerja sangat baik untuk tim yang ingin deploy cepat dan sering.

Yang paling berbahaya adalah memilih workflow yang paling kelihatan "profesional" di dokumentasi, lalu tidak benar-benar diikuti. Workflow yang sederhana dan diikuti konsisten akan selalu mengalahkan workflow kompleks yang setengah-setengah dijalankan.

"Workflow Git terbaik adalah yang tim kamu benar-benar ikuti."