Git Branching Strategy untuk Tim 1–10 Orang: Pilih yang Tepat Sebelum Merge Chaos

Tim lo bentrok tiap merge. Kode baru numbuk kode lama. Ghibah branch mana yang udah siap deploy, mana yang masih stale. Masalahnya bukan tools — tapi branching strategy yang gak cocok sama skala tim lo. Artikel ini: mana strategy untuk siapa, tanpa dogma.

Di awal karir, gue pikir branching strategy cuma soal pilih “pake GitFlow” atau “pake GitHub Flow”. Kayak pilih agama — ada yang fanatik, ada yang santai. Tapi setelah gue 3 tahun lead tim yang ganti-ganti size — dari sendirian sampe 15 developer — gue sadar: branching strategy itu alat, bukan identitas. Pilih yang salah, dan kerjaan lo terasa kayak lagi adu argumen tiap merge.

Artikel ini ringkas: 3 strategy utama — kapan lo pake, kapan lo tinggalin. Mulai.

Solo Dev (1 Orang): Lo Cuma Butuh 1 Branch

Lo sendiri. Ngerjain project sendiri. Deploy sendiri. Kenapa lo pake branching strategy rumit?

Cukup trunk-based development: commit langsung ke main, deploy tiap kali selesai fitur. Gak pake develop, gak pake feature/*, gak ada PR review. Kalau ada bug — commit fix langsung ke main, deploy ulang.

Kelebihan: nol overhead. Gak ada yang nunggu. Gak ada merge conflict karena cuma lo yang pegang kode.

Kekurangan: kalau lo hobi rebase dan commit berserakan, lo bakal punya main yang kaya koran bekas. Tapi jujur — selama lo sendirian dan gak ada audit, siapa peduli? Lo bisa cleanup setelah project jalan, bukan sebelum.

Tim Kecil (2–5 Orang): GitHub Flow

Ini sweet spot. Lo udah bukan sendirian, tapi belum perlu ritual GitFlow. Pakai GitHub Flow:

1. main selalu deployable. Selalu. Gak ada “nanti aja dibenerin”.
2. Bikin branch dari main buat tiap fitur atau bug. Nama: feat/login-otp, fix/typo-checkout.
3. PR ke main. Minimal 1 orang review (kalo ada yang ngereview).
4. PR di-merge, langsung deploy.

Kunci: branch umurnya pendek. Maksimal 2-3 hari.

Kenapa ini works buat tim kecil? Karena overhead-nya minimal — satu branch dari main, balik ke main. Gak perlu muter-muter lewat develop dulu, release dulu, hotfix dulu. Setiap fitur selesai -> deploy. Feedback loop cepet.

Batas GitHub Flow: kalau lo perlu multiple release dalam waktu bersamaan (misal version 2.1 dan 2.2 di maintain bareng), atau tim lo udah > 10 orang. Di situ GitHub Flow mulai berasa sempit.

Tim Sedang (5–15 Orang): GitFlow yang Diringanin

GitFlow klasik punya 5 branch permanen: main, develop, release/*, feature/*, hotfix/*. Itu banyak. Buat tim 5 orang, ini berasa kayak birokrasi.

Tapi buat tim dengan product yang udah punya siklus rilis terjadwal (misal: deploy tiap 2 minggu) dan support versioning — GitFlow versi light works:

• main = kode yang beredar di production. Tag tiap rilis: v2.1.0, v2.2.0.
• develop = tempat gabungin fitur minggu ini. Di sini CI jalan tiap malam. Kalau error, ketahuan sebelum ke production.
• feature/* = branch dari develop, balik ke develop via PR.
• release/* = branch dari develop, testing final. Cuma bug fix, gak ada fitur baru. Tag rilis dari sini, lalu merge ke main + develop.
• hotfix/* = branch dari main, buat bug kritis yang gak bisa nunggu rilis berikutnya. Merge ke main + develop.

Praktik yang gue temuin works: gak usah bikin release branch kalo tim lo pake CI/CD dan gak ada siklus rilis formal. Cukup develop + main + feature. Release branch baru dipake kalo lo butuh: (1) feature freeze sebelum rilis, (2) QA terpisah untuk versi tertentu, atau (3) multiple version di maintain bareng (misal: lo masih support API v1 sambil develop v2).

Yang Paling Sering Salah: Branch develop Orang Lupa di-Sync

Di GitFlow, develop jadi bottleneck. Orang merge fitur ke develop, tapi develop udah lama gak di-sync dari main. Pas mau rilis, develop jauh ketinggalan — conflict di mana-mana. Solusi: rutin sync develop dari main, setidaknya tiap hari Senin. Atau lebih baik: bikin kebiasaan “pull develop dulu sebelum bikin branch baru”.

Kalo lo udah sering kena masalah develop ketinggalan — itu tanda tim lo butuh pindah ke trunk-based atau GitHub Flow. GitFlow cuma berguna kalo develop beneran dipake sebagai “staging area”, bukan tempat sampah yang gak jelas kondisinya.

Yang Gak Pernah Dibahas Artikel Lain: Merge vs Rebase vs Squash

Banyak yang debat soal ini kaya debat agama — “merge commit bikin sejarah berantakan”, “rebase nulis ulang sejarah, jangan”, “squash kehilangan konteks tiap commit”.

Ini aturan simpel yang gue pake:

• Squash merge — buat feature/* ke develop/main. Kenapa? Karena history development di branch fitur gak berguna buat tim — yang berguna adalah “fitur X selesai”, bukan “commit 1: start bangun fitur”, “commit 2: lupa tambah validasi”, “commit 3: oops fix typo”. Preserve cuma satu commit ringkas.
• Merge commit — buat release/* ke main di GitFlow. Ini ngasih tau “ini rilis baru”. Bisa di-rollback dengan revert satu commit.
• Rebase — buat feature/* yang lagi dikerjain lebih dari 2 hari, biar gak ketinggalan dari develop. Tapi jangan rebase branch yang udah di-PR dan di-review orang lain — itu resep bencana.

Intinya: pilih cara merge yang bikin main gampang dibaca. Bukan yang paling “pure” secara git philosophy, tapi yang paling jelas kalo lo liat git log 6 bulan lagi.

Kesimpulan: Pilih yang Sesuai Ukuran Tim Lo

Gak ada branching strategy yang “paling benar”. Yang benar adalah: yang paling cocok buat tim lo hari ini. Bukan yang lo pake di startup 3 tahun lalu, bukan yang viral di Medium minggu lalu.

Mulai dari yang paling simpel (trunk-based / GitHub Flow). Tambahin complexity cuma kalo lo bener-bener ngerasa butuh. Kalo tim lo 2 orang dan lo pake GitFlow dengan 5 branch permanen — lo bikin ritual yang gak ada manfaatnya.

Dan kalo tim lo tumbuh — pindah strategy. Gak ada yang salah dengan migrasi dari GitHub Flow ke GitFlow, atau sebaliknya. Yang salah: pake strategy yang gak cocok dan maksa dengan alasan “udah kebiasaan”.