🛠️ Git Branching Strategy & Workflow Guide

Panduan resmi tata kelola branching strategy dan prosedur rilis kode untuk tim pengembang (software development team). Panduan ini dirancang agar seluruh pengembang (termasuk junior developer) memiliki pemahaman yang sama terkait alur kerja Git, pengelolaan environment, serta mitigasi risiko saat rilis.

---

📊 Visual Workflow Diagram

Berikut adalah visualisasi diagram alur kerja branch dari feature, development, staging, hingga master beserta penanganan bugfix dan hotfix:

---

📑 Daftar Isi

1. Prinsip Utama Workflow
2. Arsitektur & Matriks Branch
3. Panduan & Perlakuan di Setiap Branch
4. Struktur Penamaan Branch & Commit Message
5. Contoh Kasus End-to-End (Skenario Real-World)
6. Aturan Emas (Golden Rules)

---

1. Prinsip Utama Workflow

Workflow ini mengadopsi pendekatan Simplified Git Flow yang disesuaikan dengan 3 environment utama: Development, Staging (QA), dan Production (Master).

Konsep Kunci

1. Development sebagai Battletest Area: Tempat seluruh fitur baru dikumpulkan, diintegrasikan, dan diuji bersama (integration testing) oleh sesama developer.
2. Staging sebagai Quality Gate: Tempat verifikasi akhir oleh tim QA. Kode wajib berhasil di-deploy dan lulus pengujian 100% di Staging sebelum diizinkan menyentuh Production.
3. Master sebagai Production Reference: Menampung kode yang sedang aktif di-deploy dan diakses oleh pengguna akhir (end-user). Sangat stabil dan protected.

---

2. Arsitektur & Matriks Branch

Nama Branch	Environment Target	Tipe Branch	Source Base (Dibuat Dari)	Target Merge	Akses Direct Push
master	Production	Abadi (Protected)	-	-	DILARANG ❌
staging	Staging / QA	Abadi (Protected)	-	master	DILARANG ❌
development	Development	Abadi (Protected)	-	staging	DILARANG ❌
feature/*	Local / Dev	Temporer	development	development	BISA (Ke Branch Sendiri)
bugfix/*	Local / Staging	Temporer	staging	staging & development	BISA (Ke Branch Sendiri)
hotfix/*	Local / Prod	Temporer	master	master, staging, development	BISA (Ke Branch Sendiri)

---

3. Panduan & Perlakuan di Setiap Branch

3.1. Branch Master (Production)

• Deskripsi: Branch utama yang merepresentasikan aplikasi di server Production (live).
• Karakteristik:
  • Sangat Stabil: Tidak boleh ada kode yang eksperimental atau belum diuji.
  • Protected Branch: Membutuhkan minimal 2 approval (Tech Lead & QA Lead) untuk Merge/Pull Request.
• Perlakuan:
  • Dilarang keras melakukan git push langsung.
  • Hanya menerima merge dari branch staging (untuk rilis terjadwal) atau hotfix/* (untuk kondisi darurat).
  • Setiap kali terjadi merge ke master, wajib dibuatkan Git Tag / Release Version (contoh: v1.0.0, v1.1.0).

3.2. Branch Staging (QA / Pre-Production)

• Deskripsi: Branch pengujian akhir sebelum kode siap dilepas ke masyarakat/pengguna.
• Karakteristik:
  • Environment Staging harus dikonfigurasi 99% identik dengan Production (spesifikasi server, pustaka, hingga struktur database).
• Perlakuan:
  • Menerima merge dari branch development saat fitur-fitur yang dikumpulkan dinyatakan siap uji secara lengkap.
  • Syarat Mutlak: Pipa CI/CD harus sukses melakukan deployment tanpa error.
  • Jika ditemukan bug pada fase ini, perbaikan dilakukan melalui branch bugfix/* yang diturunkan dari staging.
  • Quality Gate: QA melakukan End-to-End Testing, Regression Testing, dan Security Audit.

3.3. Branch Development (Battletest & Integration)

• Deskripsi: Branch integrasi tempat pengumpulan seluruh hasil pekerjaan developer.
• Karakteristik:
  • Tempat terjadinya Battletest: Pengujian integrasi antar-fitur yang dibuat oleh developer berbeda.
  • Dinamis dan sering diperbarui.
• Perlakuan:
  • Tempat gabungan dari berbagai branch feature/*.
  • Apabila terjadi konflik antar-kode (merge conflict) atau kecacatan logika integrasi, pengembang menyelesaikan masalah di branch lokal masing-masing sebelum mengintegrasikan kembali.
  • Automated Unit Test dan Integration Test wajib berjalan otomatis via CI/CD setiap ada MR yang masuk ke branch ini.

3.4. Branch Feature (feature/*)

• Deskripsi: Branch temporer untuk pembuatan fitur baru atau refactoring modul tertentu.
• Perlakuan:
  • Dibuat (branched off) dari: development.
  • Di-merge kembali ke: development via MR/PR setelah lulus code review.
  • Setelah MR disetujui dan di-merge, branch ini harus dihapus (delete branch) agar repository tetap bersih.

3.5. Branch Bugfix (bugfix/*)

• Deskripsi: Branch temporer untuk menambal bug yang ditemukan oleh tim QA saat pengujian di environment Staging.
• Perlakuan:
  • Dibuat (branched off) dari: staging.
  • Di-merge ke: staging (untuk pengujian ulang oleh QA) DAN development (agar branch development tetap sinkron dan perbaikan tidak hilang).
  • Dihapus setelah perbaikan selesai dan di-merge.

3.6. Branch Hotfix (hotfix/*)

• Deskripsi: Branch darurat (urgent) untuk menangani critical bug atau system crash di server Production.
• Perlakuan:
  • Dibuat (branched off) dari: master.
  • Di-merge ke 3 branch utama sekaligus:
    1. master (di-deploy langsung ke Production).
    2. staging (agar Staging selalu membawa perbaikan terbaru).
    3. development (agar Development tidak overwrite fix ini saat rilis mendatang).
  • Wajib menaikkan versi patch tag (misal: v1.0.0 → v1.0.1).

---

4. Struktur Penamaan Branch & Commit Message

Standard Penamaan Branch

• Fitur Baru: feature/nama-fitur-singkat atau feature/ID-TASK-nama-fitur
  • Contoh: feature/JIRA-101-login-google, feature/payment-gateway-midtrans
• Bugfix (Staging): bugfix/deskripsi-singkat-bug
  • Contoh: bugfix/null-pointer-checkout, bugfix/form-validation-email
• Hotfix (Production): hotfix/deskripsi-singkat-issue
  • Contoh: hotfix/payment-callback-timeout, hotfix/memory-leak-pdf-generator

Standard Conventional Commits

Setiap commit message harus mengikuti format baku berikut:

<type>(<scope>): <deskripsi singkat dalam kalimat aktif>

Pilihan Type:

Type	Deskripsi
feat	Penambahan fitur baru
fix	Perbaikan bug
docs	Perubahan dokumentasi saja
style	Format kode, titik koma, spasi (tanpa mengubah logika)
refactor	Restrukturisasi kode tanpa menambah fitur/memperbaiki bug
test	Penambahan atau perbaikan unit test
chore	Penyesuaian skrip build, konfigurasi CI/CD, atau dependency

Contoh Commit Message:

• feat(auth): add google OAuth login endpoint
• fix(checkout): resolve price calculation discrepancy on discount promo
• docs(readme): update environment setup instructions

---

5. Contoh Kasus End-to-End (Skenario Real-World)

Kasus A: Pengembangan Fitur Baru Hingga Release

Skenario: Developer Budi mendapatkan tugas membuat fitur "Filter Produk Berdasarkan Kategori".

1. Persiapan Branch Lokal:

   git checkout development
   git pull origin development
   git checkout -b feature/product-category-filter

2. Pengembangan & Commit:

   # ... Budi koding di lokal ...
   git add .
   git commit -m "feat(product): add category filter query parameters"
   git push origin feature/product-category-filter

3. Merge ke Development (Battletest Area):

   • Budi membuat Merge Request (MR): feature/product-category-filter → development.
   • Tech Lead melakukan Code Review. Setelah Approve, MR di-merge.
   • Di branch development, fitur Budi diuji bersamaan dengan fitur Keranjang Belanja milik Siti.

4. Promosi ke Staging (QA & Deployment Test):

   • Setelah battletest aman, Tech Lead membuat MR: development → staging.
   • Sistem CI/CD secara otomatis menjalankan automated test dan men-deploy kode ke Server Staging.
   • QA melakukan pengujian menyeluruh di Staging. Skenario dinyatakan PASS.

5. Rilis ke Production:

   • Tech Lead membuat MR: staging → master.
   • Setelah di-merge, CI/CD men-deploy ke Server Production.
   • Tag rilis dibuat: v1.2.0.

---

Kasus B: Perbaikan Bug di Staging Saat QA Test

Skenario: Saat QA menguji fitur di server Staging, ditemukan bahwa tombol "Filter Kategori" mengembalikan Error 500 jika data kosong.

1. Membuat Branch Bugfix dari Staging:

   git checkout staging
   git pull origin staging
   git checkout -b bugfix/empty-category-response-500

2. Memperbaiki Logika & Push:

   # ... Budi memperbaiki null handler di controller ...
   git add .
   git commit -m "fix(product): handle empty result on category filter"
   git push origin bugfix/empty-category-response-500

3. Merge Back ke Staging & Development:

   • Buat MR ke staging. Setelah di-merge, CI/CD men-deploy ulang Staging.
   • QA melakukan re-test. Hasil: PASS.
   • Langkah Krusial: Buat MR dari bugfix/empty-category-response-500 ke development agar perbaikan tersebut juga berada di branch development.

---

Kasus C: Perbaikan Critical Hotfix di Production

Skenario: Pada jam 2 siang di Production, aplikasi crash saat pengguna melakukan checkout dengan metode pembayaran QRIS.

1. Isolasi Masalah via Hotfix Branch dari Master:

   git checkout master
   git pull origin master
   git checkout -b hotfix/qris-null-payload-crash

2. Perbaikan Cepat (Fast Fix):

   # ... Senior Dev membenarkan parsing payload QRIS ...
   git add .
   git commit -m "fix(payment): add safety check for empty QRIS payload response"
   git push origin hotfix/qris-null-payload-crash

3. Deployment Emergency ke Production:

   • MR hotfix/qris-null-payload-crash → master di-approve secara prioritas oleh Tech Lead.
   • Setelah di-merge, CI/CD men-deploy perbaikan langsung ke Production.
   • Buat Release Tag baru: v1.2.1.

4. Sinkronisasi Kembali (Sync-Back):

   • Merge hotfix/qris-null-payload-crash ke branch staging.
   • Merge hotfix/qris-null-payload-crash ke branch development.
   • Hapus branch hotfix/qris-null-payload-crash.

---

6. Aturan Emas (Golden Rules)

1. 🚫 NEVER DIRECT PUSH TO PROTECTED BRANCHES: Dilarang keras melakukan git push langsung ke master, staging, maupun development. Selalu gunakan Pull Request / Merge Request.
2. 🔄 UPDATE LOCAL BEFORE CREATING BRANCH: Selalu lakukan git pull origin <base-branch> sebelum membuat branch baru agar terhindar dari konflik kode yang tidak perlu.
3. 🧹 DELETE FEATURE BRANCH AFTER MERGE: Hapus branch temporer (feature/*, bugfix/*, hotfix/*) baik di remote repository maupun lokal setelah MR berhasil di-merge.
4. 💬 DESCRIPTIVE COMMITS & MERGE REQUESTS: Jelaskan apa yang diubah dan mengapa perubahan itu dibuat pada deskripsi MR. Sertakan screenshot atau video bukti jika ada perubahan UI.
5. 🛡️ STAGING MUST PASS DEPLOYMENT & QA: Jangan pernah merilis kode ke master jika deployment Staging gagal atau jika masih terdapat unresolved issue dari tim QA.