Git Branching Strategy: Branching Model untuk Tim

Pernah nggak sih ngerasa kebingungan saat kerja bareng tim pakai Git? Satu orang bikin branch, satu lagi langsung push ke main, ada yang lupa merge, dan tiba-tiba kode yang diproduksi udah broken sebelum bisa ditarik siapa pun? 🤯

Kalau pernah, tenang aja — itu tanda tim kamu butuh branching strategy yang jelas.

Di tutorial kali ini, kita bakal bahas berbagai model branching di Git yang populer dipakai tim-tim developer. Mulai dari yang paling "formal" sampai yang paling simpel, dan kapan harus pakai yang mana.

Table of Contents

1. Kenapa Branching Strategy Penting?
2. Konsep Dasar Branching di Git
3. Git Flow
4. GitHub Flow
5. GitLab Flow
6. Trunk-Based Development
7. Kapan Pakai yang Mana?
8. Tips Praktis untuk Tim
9. Kesimpulan

Kenapa Branching Strategy Penting?

Bayangkan kamu punya proyek web yang dikerjakan bareng 5 orang. Semua ngoding di satu branch yang sama. Tanpa aturan yang jelas, kamu bakal mengalami:

• Merge conflict yang tiada habisnya
• Kode broken yang ke-deploy ke produksi
• Sulit mengontrol fitur mana yang udah siap dan mana yang belum

Branching strategy itu kayak aturan jalan raya untuk tim developer. Tanpa rambu-rambu, semua orang bisa jalan ke mana aja dan akhirnya tabrakan.

Konsep Dasar Branching di Git

Sebelum masuk ke strategi spesifik, pahami dulu istilah-istilah dasar:

Git Flow

Git Flow adalah model branching yang dipopulerkan oleh Vincent Driessen pada tahun 2010. Ini adalah salah satu strategi branching paling terstruktur yang banyak dipakai tim-tim besar.

Struktur Branch

main (production)
  │
  ├── hotfix/fix-payment-bug
  │
  └── release/v2.1.0
       │
       └── develop
            ├── feature/user-auth
            ├── feature/payment-system
            └── feature/dashboard

Cara Pakai

# Inisialisasi Git Flow
git flow init
 
# Mulai fitur baru
git flow feature start user-authentication
# ... kerja, commit ...
git commit -m "feat: add login form component"
git commit -m "feat: implement JWT token handling"
git flow feature finish user-authentication
 
# Persiapan release
git flow release start v2.1.0
# ... update version, CHANGELOG ...
git commit -m "chore: bump version to 2.1.0"
git flow release finish v2.1.0
 
# Hotfix (perbaikan darurat)
git flow hotfix start fix-payment-crash
# ... fix bug ...
git commit -m "fix: handle null pointer in payment"
git flow hotfix finish fix-payment-crash

Kelebihan & Kekurangan

• ✅ Sangat terstruktur dan jelas
• ✅ Cocok untuk proyek dengan jadwal release tetap
• ❌ Terlalu kompleks untuk proyek kecil atau startup
• ❌ Banyak branch yang harus dikelola

GitHub Flow

GitHub Flow adalah model branching yang lebih simpel, hanya menggunakan satu branch utama (main) dan branch fitur. Semua perubahan masuk ke main melalui pull request.

Prinsip Utama

1. Branch main selalu bisa di-deploy
2. Semua perubahan harus lewat pull request dan code review
3. Setelah merge, langsung deploy ke produksi

Alur Kerja

main ──●──●──●──●──●──●── (production ready)
        \  /    \  /
         \/      \/
     feature-A  feature-B

Cara Pakai

# Buat branch dari main
git checkout main
git pull origin main
git checkout -b feature/add-search
 
# Kerja dan commit
git add .
git commit -m "feat: add search with debounce"
git push origin feature/add-search
 
# Buka pull request
gh pr create --title "feat: Add search functionality"
 
# Code review → approve → merge → deploy

Kelebihan & Kekurangan

• ✅ Simpel dan mudah dipahami
• ✅ Cocok untuk continuous deployment
• ❌ Kurang cocok untuk release cycle yang panjang
• ❌ Butuh discipline tinggi untuk menjaga main stabil

GitLab Flow

GitLab Flow adalah kompromi antara Git Flow yang kompleks dan GitHub Flow yang terlalu simpel. Fitur utamanya: branch main + branch environment + branch release.

Dua Pola Utama

Pola Environment Branching:

main ──────●─────●─────●─────
             \     \     \
              v     v     v
            staging  production

Pola Release Branching (multi-version support):

main ──────●─────●─────●─────
             \     \     \
              v     v     v
          17.0  17.1  17.2

Cara Pakai

# Kerja di fitur, push ke main setelah review
git checkout -b feature/new-api
git commit -m "feat: add /api/users endpoint"
# ... MR, review, merge ke main ...
 
# Promote ke staging
git checkout staging
git merge main
git push origin staging
# Deploy ke staging otomatis
 
# Setelah QA approve, promote ke production
git checkout production
git merge staging
git push origin production
# Deploy ke production otomatis

Kelebihan & Kekurangan

• ✅ Fleksibel, bisa disesuaikan dengan kebutuhan tim
• ✅ Ada mekanisme promosi environment yang jelas
• ❌ Butuh pemahaman lebih dalam tentang kebutuhan tim

Trunk-Based Development

Trunk-Based Development adalah model di mana semua developer bekerja di satu branch utama. Branch fitur bersifat sangat pendek (paling lama 1-2 hari) atau bahkan nggak ada sama sekali. Ini model yang dipromosikan oleh Google, Facebook, dan banyak perusahaan besar.

Prinsip Utama

1. Semua orang kerja di main
2. Branch fitur harus pendek (idealnya < 1 hari)
3. Gunakan feature flags untuk mengontrol fitur baru
4. Continuous integration diutamakan

Contoh Implementasi

// Feature flags
const featureFlags = {
  new_checkout: process.env.FF_NEW_CHECKOUT === 'true',
  dark_mode: process.env.FF_DARK_MODE === 'true',
};
 
// Di kode kamu
function CheckoutComponent() {
  if (featureFlags.new_checkout) {
    return <NewCheckout />;
  }
  return <LegacyCheckout />;
}

# Workflow harian
git pull origin main
git checkout -b feat/short-lived
# ... kerja, commit, push (dalam hitungan jam) ...
git push origin feat/short-lived
# Buka MR kecil, review cepat, merge
git branch -d feat/short-lived

Kelebihan & Kekurangan

• ✅ Sangat cepat untuk continuous deployment
• ✅ Mengurangi merge conflict karena branch selalu pendek
• ❌ Butuh CI/CD pipeline yang sangat kuat
• ❌ Testing harus sangat menyeluruh

Kapan Pakai yang Mana?

Tip: Mulai dari yang sederhana (GitHub Flow), upgrade ke strategi yang lebih kompleks kalau dibutuhkan.

Tips Praktis untuk Tim

1. Dokumentasikan Strategy

Buat file BRANCHING.md di root repo:

# Branching Strategy
- `main` — Production code, always deployable
- `feature/*` — New features, from main
- `bugfix/*` — Bug fixes, from main
 
## Rules
- Never force push to main
- All changes need approval
- CI must pass before merge

2. Branch Naming Convention

feature/user-registration
bugfix/login-error-mobile
hotfix/security-patch-xss
release/v2.1.0

3. Auto-Cleanup Branch

# .github/workflows/cleanup.yml
name: Branch Cleanup
on:
  pull_request:
    types: [closed]
jobs:
  delete-branch:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/github-script@v6
        with:
          script: |
            github.rest.git.deleteRef({
              owner: context.repo.owner,
              repo: context.repo.repo,
              ref: `heads/${context.headRef}`
            })

4. Conventional Commits

feat: menambahkan fitur search
fix: memperbaiki bug login di mobile
docs: update API documentation
test: menambahkan unit test untuk payment

Kesimpulan

Git branching strategy bukan soal mana yang paling "keren" — tapi mana yang paling cocok untuk situasi tim kamu sekarang.

Yang terpenting:

1. Pilih satu strategi dan konsisten dipakai seluruh tim
2. Dokumentasikan supaya semua orang paham
3. Review dan adapt setiap beberapa bulan
4. Jangan takut berubah kalau strategi yang sekarang udah gak cocok

Branching strategy yang bagus itu yang bikin tim kamu lebih produktif, bukan yang bikin workflow jadi lebih ribet.

Selamat mencoba, dan semoga coding session kamu dan tim jadi lebih lancar! 🚀

Punya pengalaman pakai branching strategy tertentu? Tulis di kolom komentar, yuk!