Belajar Git Branching Strategies - Sejarah, Latar Belakang & Mengapa Membutuhkan Branching Strategy
Memahami masalah kolaborasi tanpa branching strategy — race condition, merge conflict tak terelakkan, branch naming acak, dan release unpredictable — serta evolusi dari trunk-based VCS ke strategi branching modern yang menjadikan workflow dan governance tim sebagai inti permasalahan.
#Pendahuluan
Setelah di episode 0 kita menyiapkan environment — Git terinstall, VS Code dengan GitLens siap, dan repo sandbox ~/branching-lab dibuat — pada episode ini kita menarik napas sejenak dari hands-on dan memahami mengapa branching strategy ada. Sejarah sebuah konsep mungkin terasa tidak penting, padahal justru di sanalah letak alasan mengapa strategy seperti sekarang.
Mengapa harus memahami mengapa branching strategy diperlukan? Karena tanpa konteks masalah yang diselesaikan, kalian akan menghafal aturan tanpa mengerti trade-off di baliknya. Dan di sinilah letak perbedaan developer yang memilih strategy vs yang mengikuti template.
#Masalah Kolaborasi Tanpa Branching Strategy
Bayangkan tim 5 developer bekerja di satu branch yang sama — main. Setiap orang push setiap jam. Apa yang terjadi?
#Race Condition dan Merge Conflict
Ketika banyak developer mengedit file yang sama secara bersamaan, Git akan meminta kalian menyelesaikan merge conflict setiap kali push. Bayangkan sprint pertengahan: 3 developer mengubah UserService.ts secara bersamaan. Kalian menghabiskan lebih banyak waktu menyelesaikan konflik daripada menulis kode baru.
#Branch Naming Acak
Tanpa konvensi, branch menjadi战场:
fix-bug-1john-new-featurefinal-fix-v2really-final-fix
Developer baru yang melihat daftar branch tidak tahu mana yang sedang aktif, mana yang sudah selesai, mana yang harus di-merge. Branch lama menumpuk seperti sampah — tak ada yang berani menghapus karena takut kehilangan kode.
#Release Unpredictable
Tanpa branch khusus release, kalian tidak tahu kapan kode siap di-deploy. Apakah main selalu bisa di-deploy? Tidak — ada half-finished features, experimental code, dan perbaikan yang belum teruji. Kalian membutuhkan cara untuk memisahkan kode yang siap dari kode yang belum siap.
#Evolusi Branching Strategy
#Dari SVN ke Git
Di era SVN (Centralized VCS), konsep branch berbeda: branch adalah salinan lengkap dari seluruh kode — berat dan lambat. Developer cenderung menghindari branch karena overhead-nya.
Git mengubah permainan: branch di Git adalah pointer ringan ke commit — tidak ada salinan kode. Membuat branch semurah membuat file. Inilah yang memungkinkan branching strategy modern: branch bisa dibuat, digabungkan, dan dihapus dalam hitungan detik.
#Key Insight
Branching strategy bukan soal Git — Git bisa melakukan apa pun. Branching strategy adalah soal workflow dan governance tim: bagaimana kode mengalir dari ide ke production, siapa yang boleh merge ke mana, dan kapan kode dianggap siap.
Graf di atas menunjukkan alur sederhana: kode mengalir dari main ke develop, fitur dibuat di branch terpisah, lalu di-merge kembali. Tanpa visualisasi seperti ini, tim kehilangan jejak alur kode.
#Mengapa Branching Strategy Penting
Empat alasan utama yang membuat branching strategy menjadi kebutuhan, bukan pilihan:
| Alasan | Dampak Tanpa Strategy |
|---|---|
| Predictable release cadence | Deploy dadakan, kapan saja, tanpa jadwal |
| Isolasi fitur, hotfix, eksperimen | Kode setengah jadi bercampur dengan kode production |
| Code review workflow terstruktur | Direct push ke main tanpa review |
| Integrasi CI/CD yang konsisten | Pipeline trigger acak, tidak ada gating |
Branching strategy yang baik menjawab pertanyaan-pertanyaan ini:
- Kapan saya membuat branch baru?
- Dari mana branch baru itu lahir?
- Ke mana branch itu di-merge setelah selesai?
- Siapa yang boleh merge ke branch tertentu?
- Kapan branch boleh dihapus?
Tanpa jawaban yang jelas, setiap developer membuat aturannya sendiri — dan itulah awal dari kekacauan.
#Penutup
Pada episode 1 ini, kalian telah memahami mengapa branching strategy diperlukan:
- Kolaborasi tanpa strategy menghasilkan race condition, merge conflict, branch naming acak, dan release unpredictable.
- Evolusi dari SVN ke Git memungkinkan branch ringan — tetapi ringan saja tidak cukup tanpa workflow yang jelas.
- Branching strategy adalah soal workflow dan governance tim, bukan tentang flag Git.
- Predictable release, isolasi kode, code review, dan CI/CD integration adalah empat pilar utama.
Di episode 2 selanjutnya kita akan mempelajari konsep dasar branching dan visualisasi dengan Mermaid — memahami branch sebagai pointer, merge vs rebase, dan fast-forward vs non-fast-forward. Kita akan mulai menggunakan diagram untuk memvisualisasikan alur kerja. Sampai jumpa di episode 2!