Belajar Git Branching Strategies - Long-Lived Branches vs Short-Lived Branches

#Pendahuluan

Setelah di episode 13 kita mempelajari Branch Naming Convention — naming yang konsisten untuk filtering dan automasi — pada episode ini kita membahas perbedaan kritis antara branch yang hidup lama dan branch yang hidup pendek. Pemilihan durasi branch memiliki dampak besar pada jumlah merge conflict, kemudahan review, dan kesehatan repository.

Ini adalah salah satu aspek paling penting dari branching strategy: seberapa lama branch kalian hidup menentukan seberapa sering kalian mengalami masalah integrasi.

#Short-Lived Branches (Recommended)

Short-lived branch hidup beberapa jam sampai beberapa hari. Ini adalah rekomendasi untuk branch feature, bugfix, dan hotfix.

#Keunggulan

Sering di-merge → mengurangi divergence dari main.
Merge conflict kecil → perubahan kecil, lebih mudah diselesaikan.
PR kecil → lebih mudah di-review.
CI/CD lebih cepat → pipeline berjalan lebih sering, feedback lebih cepat.

#Contoh

Short-lived feature branch

# Hari 1: buat branch, kerja, push, buka PR
git switch -c feature/add-search
# ... commit beberapa kali ...
git push -u origin feature/add-search
# Buka PR, review, merge dalam 1-2 hari
 
# Hari 2: branch sudah di-merge dan dihapus

Branch hidup selama 1-2 hari, di-merge, dihapus. Bersih.

#Long-Lived Branches

Long-lived branch hidup berminggu-minggu, berbulan-bulan, atau permanen. Beberapa memang harus panjang:

Branch	Durasi	Alasan
`main` / `master`	Permanen	Branch utama production
`develop`	Permanen	Branch integrasi (GitFlow)
`stable-*`	Permanen	Maintenance versi lama
`release/*`	Mingguan	Persiapan rilis
Feature branch	Jangan lama	Berisiko tinggi

#Bahaya Long-Lived Feature Branch

Ketika feature branch hidup terlalu lama, beberapa masalah muncul:

1. Merge Conflict Besar

Semakin lama branch hidup, semakin banyak main bergerak maju. Saat akhirnya di-merge, perbedaan sudah sangat besar → conflict ratusan baris.

2. Integration Hell

Branch sudah sangat berbeda dari main. Kode di main sudah berubah, API sudah berubah, library sudah di-update. Kalian harus menyelesaikan semua ini sebelum merge.

3. Sulit di-Review

PR dari branch yang hidup berminggu-minggu bisa mencapai ribuan baris. Reviewer kewalahan, kualitas review menurun, bug terlewat.

#Solusi untuk Mengurangi Dampak

#Sync/Rebase Secara Berkala dari Main

Sync feature branch dengan main secara berkala

git switch feature/long-running
git fetch origin
git rebase origin/main

Rebase secara berkala (minimal sekali sehari) menjaga feature branch tetap dekat dengan main. Conflict menjadi kecil dan sering, bukan besar dan menakutkan.

#Gunakan Feature Flags

Kode yang belum siap di-deploy bisa di-merge ke main tetapi disembunyikan dengan feature flag. Ini memungkinkan integrasi berkelanjutan tanpa risiko.

#Split Branch Besar menjadi Sub-Branch Kecil

Jika feature branch sudah sangat besar, pertimbangkan untuk memecahnya menjadi beberapa branch kecil yang di-merge secara bertahap.

Warning

Long-lived feature branch adalah salah satu penyebab utama "merge hell" di tim. Jika feature membutuhkan waktu berminggu-minggu, gunakan feature flags dan sync berkala dengan main. Jangan biarkan branch hidup terlalu lama tanpa integrasi.

#Penutup

Pada episode 14 ini, kalian telah memahami perbedaan Long-Lived vs Short-Lived Branches:

Short-lived (jam-hari): recommended untuk feature, bugfix, hotfix. Mengurangi conflict dan memudahkan review.
Long-lived (permanent): hanya untuk main, develop, stable-*. Jangan untuk feature branches.
Bahaya long-lived feature: merge conflict besar, integration hell, PR sulit di-review.
Solusi: sync/rebase berkala, feature flags, split branch besar.

Di episode 15 selanjutnya kita akan mempelajari Trunk-Based Development untuk Tim Besar — scaling TBD dengan feature flags management, branch by abstraction, dan TDD untuk memastikan setiap commit ke main aman. Sampai jumpa di episode 15!