Strategi Branching

Tujuh belas chapter sejak awal section ini memperlakukan percabangan sebagai keputusan teknis: kapan branch dibuat, kapan digabung, bagaimana konfliknya diselesaikan. Pada kenyataannya, keputusan paling menentukan bukan bagaimana memakai branch, melainkan branch apa yang kita buat dan mengapa. Pilihan pola percabangan menentukan kecepatan tim, risiko rilis, sampai beban housekeeping seperti yang baru kita latihan di chapter Menghapus Branch . Chapter penutup ini memetakan empat pola yang paling sering dipakai proyek nyata, merangkum konvensi penamaannya, lalu menghubungkan semuanya dengan workflow tim — pembahasan yang berlanjut di section kolaborasi.

Empat Pola Branch di Proyek Nyata #

Pola	Contoh nama	Dipakai saat	Nasib setelah tugas
Branch per fitur	`fitur/pencarian`	tiap pekerjaan baru yang bukan perbaikan kecil	dihapus setelah merge
Branch per rilis	`release/1.2`	menjelang rilis: fitur dibekukan, hanya bug dibereskan	bertahan selama versi hidup, ditandai tag
Branch per hotfix	`hotfix/token-kedaluwarsa`	darurat di versi produksi, kecil dan terburu	merge balik ke main dan rilis, lalu dihapus
Branch per orang	`budi/eksperimen-tema`	eksperimen panjang atau pekerjaan pribadi yang tak boleh mengganggu	seumur pemiliknya, bebas dihapus kapan saja

Empat pola itu menjawab empat kebutuhan yang berbeda. Branch per fitur adalah unit kerja standar: satu concern, satu branch, satu merge — chapter Three-Way Merge sampai git merge dibangun untuk alur ini. Branch per rilis membelah riwayat di titik stabil: setelah release/1.2 lahir, ia hanya menerima perbaikan; fitur baru terus masuk ke main dan menunggu rilis berikutnya. Branch per hotfix berangkat dari titik rilis yang sedang dipakai produksi — bukan dari ujung main — supaya perbaikan tidak terseret fitur yang belum selesai; hasilnya digabungkan balik ke main dan ke branch rilis. Branch per orang paling bebas: tempat parkir pekerjaan setengah jadi yang tidak boleh bocor ke branch utama.

Konvensi Penamaan yang Dipatuhi Tim #

Nama branch yang baik itu pendek, huruf kecil dengan tanda hubung (kebab-case), diawali prefix jenis pekerjaan, dan menyebut tugas — bukan orang. Empat nama berikut hidup berdampingan dalam satu repository latihan:

bash
mkdir latihan-strategi && cd latihan-strategi
git init -b main
git config user.name "Budi Santoso"
git config user.email "[email protected]"
printf '# Situs toko\nberanda\n' > situs.md
git add situs.md
git commit -m "Susun kerangka situs"
git branch fitur/pencarian
git branch release/1.2
git branch hotfix/token-kedaluwarsa
git branch budi/eksperimen-tema
git branch
git branch --list 'fitur/*'

Output yang Dihasilkan (perintah git branch):

text
  budi/eksperimen-tema
  fitur/pencarian
  hotfix/token-kedaluwarsa
* main
  release/1.2

Output yang Dihasilkan (perintah git branch --list 'fitur/*'):

text

  fitur/pencarian

Contoh Graf Riwayat #

Dipetakan ke graf, kombinasi pola-pola itu terlihat seperti berikut (dibaca dari kiri ke kanan; panah menunjuk ke commit parent, sama seperti graf git log --graph):

flowchart RL M2["Merge hotfix ke main"] --> M1["Merge fitur pencarian"] M2 --> H["hotfix/token-kedaluwarsa"] M1 --> C["main menampung fitur lain"] M1 --> F["fitur/pencarian"] H --> R["release/1.2"] C --> P["Pekerjaan awal main"] F --> P R --> P P --> K["Kerangka situs"] T["tag v1.2.0"] -.-> R

Alur ceritanya: dari pekerjaan awal main lahir dua cabang — fitur/pencarian untuk fitur baru dan release/1.2 untuk pembekuan rilis. Fitur pencarian selesai dan digabungkan ke main (commit merge M1). Sebuah bug darurat ditemukan di rilis, diperbaiki pada hotfix/token-kedaluwarsa yang berangkat dari release/1.2, lalu digabungkan balik ke main pada M2 — dan versi rilis yang sudah stabil ditandai tag v1.2.0. Tiga pola, satu graf, tanpa satu pun commit saling menimpa.

Dari Pola ke Workflow Tim #

Pola percabangan menjadi workflow begitu ditambah aturan main: siapa boleh merge ke main, apakah merge lewat pull request, apakah main wajib selalu siap rilis. Tiga aliran yang paling berpengaruh:

Feature Branch Workflow — semua pekerjaan di branch fitur, main dijaga selalu sehat; pola paling umum untuk tim kecil-menengah.
Gitflow — formalisasi penuh dari pola rilis dan hotfix di atas: branch develop, release/, hotfix/ dengan tugas yang dibakukan; pas untuk proyek dengan siklus rilis terjadwal.
Trunk-Based Development — kebalikan ekstremnya: hampir semua commit langsung ke main, branch hidup hanya beberapa jam; andalan tim dengan integrasi berkelanjutan.

Pilihan di antaranya bukan soal benar-salah, melainkan ukuran tim, frekuensi rilis, dan selera risiko. Uraian resmi Pro Git atas pola-pola ini bisa dibaca di git-scm.com/book/en/v2/Git-Branching-Branching-Workflows ; pembahasan mendalam tiap workflow menunggu di section Kolaborasi Tim .

Di titik ini section Branch dan Merging tuntas: branch sebagai penunjuk, penggabungan tiga babaknya, konflik dan penyelesaiannya, alat bantunya, pembatalan, housekeeping, dan strategi. Satu batas terakhir masih berdiri: semuanya terjadi di satu mesin. Kedua tangan berikutnya milik pekerjaan bersama — repository jauh di server, git push, git fetch, dan kolaborasi lintas meja. Gerbangnya ada di section Remote Repository .