Strategi Branching - Git Flow, GitHub Flow & Trunk-Based — Belajar Git & CI/CD

1. Git Flow

main      ──●───────────●───────────●──   (hanya rilis, diberi tag)
             \         /         /
release       \    ●─●       ●─●
               \  /         /
develop    ●────●─────●────●──────────    (integrasi harian)
            \        /
fitur        ●──────●
hotfix    ──────●──────────────────●      (langsung dari & ke main)

Branch	Umur	Peran
`main`	Permanen	Hanya berisi kode yang sudah dirilis, tiap commit diberi tag versi
`develop`	Permanen	Tempat integrasi seluruh fitur yang sedang dikembangkan
`feature/*`	Hari–minggu	Bercabang dari develop, kembali ke develop
`release/*`	Hari	Pembekuan fitur; hanya perbaikan bug dan penyiapan rilis
`hotfix/*`	Jam	Dari main langsung, digabungkan ke main dan develop

⚠️ Git Flow sering dipakai di tempat yang salah

Penulis aslinya sendiri kemudian menambahkan catatan bahwa model ini dirancang untuk perangkat lunak berversi eksplisit yang harus mendukung beberapa versi sekaligus — misalnya aplikasi desktop, pustaka, atau perangkat yang dipasang di tempat pelanggan. Untuk aplikasi web yang dirilis beberapa kali sehari, Git Flow menambahkan banyak upacara tanpa manfaat sepadan.

Pakai bila: ada rilis terjadwal, beberapa versi harus dipelihara bersamaan, ada tahap QA formal.
Hindari bila: Anda men-deploy aplikasi web setiap hari.

2. GitHub Flow

main   ●───●───●───●───●───●──   (selalu bisa di-deploy)
        \     /     \   /
fitur    ●───●       ●─●

Alurnya:
1. Bercabang dari main
2. Commit, push, buka pull request
3. CI berjalan, rekan tim me-review
4. Deploy dari branch untuk diuji (opsional)
5. Merge ke main -> otomatis ter-deploy

Hanya satu branch permanen: main.
Aturan tunggal yang mutlak: main harus selalu bisa di-deploy.
Branch fitur berumur pendek — idealnya kurang dari beberapa hari.

Ini model yang paling banyak dipakai tim produk web saat ini: sederhana, cocok dengan pull request, dan langsung terhubung ke continuous deployment.

3. Trunk-Based Development

main  ●─●─●─●─●─●─●─●─●─●─●─●──  (semua orang, setiap hari)
       \/ \/ \/ \/ \/ \/
      branch berumur beberapa JAM saja

Setiap pengembang mengintegrasikan ke main setidaknya sekali sehari. Branch hidup dalam hitungan jam, bukan hari.

💡 Bagaimana fitur besar dikerjakan tanpa branch panjang?

Jawabannya: feature flag. Kode yang belum selesai tetap digabungkan ke main, tetapi jalurnya dimatikan saat dijalankan.

if (flag.aktif("checkout-versi-baru", pengguna)) {
    return checkoutBaru(pesanan);
}
return checkoutLama(pesanan);

Ini memisahkan proses deploy dari proses rilis: kode bisa berada di produksi berhari-hari sebelum benar-benar dinyalakan, dan bisa dimatikan seketika tanpa perlu deploy ulang bila bermasalah.

⚠️ Feature flag adalah utang teknis yang wajib dilunasi

Flag yang tidak pernah dibersihkan menumpuk menjadi percabangan kode yang tak terkelola. Tetapkan tanggal kedaluwarsa saat membuat flag, dan hapus jalur kode lama segera setelah fitur baru terbukti stabil.

4. Memilih Model yang Tepat

Situasi	Model yang tepat
Aplikasi web SaaS, deploy harian, tim 3–15 orang	GitHub Flow
Deploy beberapa kali sehari, CI/CD sangat matang, tes otomatis kuat	Trunk-Based
Aplikasi mobile atau desktop dengan siklus rilis toko aplikasi	Git Flow atau varian dengan branch rilis
Pustaka open source dengan banyak versi yang dipelihara	Git Flow + branch pemeliharaan per versi mayor
Proyek satu orang	main saja, plus branch bila mengerjakan hal berisiko

5. Melindungi Branch Utama

Aturan yang sebaiknya diaktifkan pada main

✓ Wajib melalui pull request sebelum merge
✓ Wajib mendapat minimal 1 persetujuan review
✓ Persetujuan lama dibatalkan bila ada commit baru
✓ Wajib lulus semua pemeriksaan CI (build, tes, lint, pemindaian keamanan)
✓ Wajib branch mutakhir terhadap main sebelum merge
✓ Wajib percakapan review terselesaikan
✓ Larang force push
✓ Larang penghapusan branch
✓ Wajib commit bertanda tangan (untuk lingkungan yang diatur ketat)

CODEOWNERS — review otomatis oleh pemilik area

# .github/CODEOWNERS
*                     @tim-inti
/src/pembayaran/**    @tim-pembayaran
/infra/**             @tim-platform
*.sql                 @tim-basis-data

6. Tag dan Versi Semantik

# Tag beranotasi -- selalu pakai ini untuk rilis,
# karena menyimpan pengarang, tanggal, dan pesan
git tag -a v2.4.0 -m "Rilis 2.4.0 - checkout cepat"

git tag                    # daftar semua tag
git show v2.4.0
git push origin v2.4.0
git push origin --tags

# Deskripsi versi dari tag terdekat -- berguna untuk menandai build
git describe --tags
# => v2.4.0-12-g4a1de8f  (12 commit setelah v2.4.0)

💡 Semantic Versioning: MAYOR.MINOR.PATCH

MAYOR — ada perubahan yang merusak kompatibilitas.
MINOR — fitur baru, tetap kompatibel ke belakang.
PATCH — perbaikan bug, tetap kompatibel.

Bila Anda memakai Conventional Commits, alat seperti semantic-release dapat menentukan nomor versi, membuat changelog, dan memasang tag secara otomatis di dalam pipeline CI — tanpa keputusan manual.