Pesan commit yang rapi menjaga kualitas tiap unit kerja; strategi branching menentukan bagaimana unit-unit itu menyusun riwayat tim. Chapter ini membandingkan lima strategi yang dibahas tuntas di section kolaborasi dan praktik — dari yang tanpa upacara sampai yang berlapis lima jenis branch — lalu menutupnya dengan tabel penamaan branch dan tabel kapan rilis cukup dari main. Cara pakainya: baca baris paling sederhana yang menjawab ukuran tim dan ritme produk kita, jangan baris yang paling terkenal. Kerangka empat pertanyaan lengkapnya — jumlah kontributor, jenis produk, kematangan CI, budaya review — ada di Memilih Workflow yang Tepat
; matriks rekomendasinya memetakan kombinasi yang paling umum ke strategi di tabel berikut.
Lima Strategi dalam Satu Tabel #
Kolom berat mengukur banyaknya aturan dan cabang yang harus dijaga — bukan kualitas: strategi terbaik adalah yang paling sederhana namun menjawab masalah tim. Semua baris memakai peralatan yang sudah dibedah di contekan perintah; bedanya hanya pada siapa boleh commit ke mana dan kapan pekerjaan menyatu.
| Strategi | Cabang dipakai | Integrasi | Cocok untuk | Berat |
|---|---|---|---|---|
| Single main (Proyek Pribadi ) | hanya main | commit langsung ke main, rilis lewat tag | pekerja solo dengan cadangan git bundle | paling ringan |
| Feature branch (Feature Branch Workflow ) | main + fitur/* | merge (kadang rebase dulu) ke main, review sebelum gabung | tim kecil-menengah dengan review per fitur | sedang |
| GitHub Flow (GitHub Flow ) | main + branch deskriptif pendek | pull request + merge; deploy menyusul merge | web yang deploy terus-menerus | ringan |
| Trunk-based (Trunk-Based Development ) | main; branch hidup <1 hari | commit kecil langsung atau PR kecil, feature flag menutup fitur setengah jadi | tim 6+ dengan CI matang | aturan ringan, disiplin berat |
| GitFlow (GitFlow ) | main, develop, feature/*, release/*, hotfix/* | merge berlapis; main hanya bergerak saat rilis + tag | rilis terjadwal dengan beberapa versi hidup | paling berat |
Menamai Branch #
Nama branch adalah pengumuman niat — PR sering dibuka jauh sebelum pekerjaan selesai, jadi nama yang deskriptif sudah menceritakan isinya. Konvensinya: prefix jenis pekerjaan menyusul kebab-case yang menyebut tugasnya — fitur/kontak bukan siti (Strategi Branching
, GitHub Flow
).
| Pola nama | Berangkat dari | Kapan dipakai |
|---|---|---|
fitur/pencarian | main (atau develop di GitFlow) | satu fitur terisolasi sampai matang |
perbaikan/footer-miring | main | koreksi kecil di jalur PR — padanan umum bugfix/* |
release/1.2 | main atau develop | pembekuan calon rilis; sejak lahir hanya menerima perbaikan |
hotfix/token-kedaluwarsa | tag rilis atau main | darurat produksi — merge balik ke main dan branch rilis |
Rilis dari main atau dari Branch Rilis #
Dua jalur menutup kebutuhan yang berbeda: produk yang bisa dikirim kapan saja cukup membekukan titik di main, produk multi-versi membutuhkan branch yang hidup selama versinya dirawat. Pembedanya satu pertanyaan — apakah beberapa versi hidup bersamaan di tangan pengguna (Koordinasi Release
).
| Situasi | Jalur rilis |
|---|---|
| Deploy terus-menerus (GitHub Flow) | tag pada main — tanpa branch rilis (GitHub Flow
) |
| Rilis terjadwal, satu-dua versi hidup | git switch -c release/1.2 main, stabilisasi, tag, merge balik (Workflow Release
) |
| Darurat di versi produksi | hotfix/* dari tag rilis, naikkan PATCH, merge balik dua jalur (Workflow Hotfix
) |
Riwayat tim yang sehat pun tetap menabrak masalah: push ditolak, HEAD terlepas, berkas lenyap, hook diam di clone baru. Dua belas gejala seperti itu beserta penyebab dan penawarnya dirangkum dalam tabel keputusan chapter berikutnya: Troubleshooting .