# Manajemen Git Branching Strategy Skala Besar untuk Tim Multi-Squad

> Diterbitkan oleh Literally Web ID pada 21 Oct 2026
> Sumber: https://literally.web.id/articles/manajemen-git-branching-strategy-skala-besar-untuk-tim-multi-squad

---

Dalam 15 menit ke depan, kita akan merakit strategi manajemen Git branching skala besar dari nol sampai berjalan mulus. Pengalaman bertahun-tahun menangani infrastruktur web dengan puluhan squad membuktikan bahwa bencana rilis bukan berasal dari bug kodenya, melainkan dari kekacauan merge di repository utama. Bayangkan ada 50 engineer mendorong kode secara bersamaan ke branch `main`, mengandalkan server CI/CD yang megap-megap menjalankan Nginx, PHP-FPM, dan query MySQL yang menumpuk. Tanpa aturan main yang ketat, kita hanya menunggu waktu hingga aplikasi down. Mari kita bedah resep praktisnya agar dapur rilis kita tetap bersih dan terkendali.

## 1. Menu Kita Hari Ini & Alat yang Perlu Disiapkan
Sebelum mulai meracik, pastikan meja kerja kita sudah bersih dari asumsi usang. Hari ini kita tidak akan memakai Gitflow tradisional yang bikin proses rilis berbelit-belit hingga berminggu-minggu, tapi kita juga tidak akan langsung melepas semua squad ke *Trunk-Based Development* mentah-mentah yang berisiko melumpuhkan environment staging. Kita akan memadukan ketangguhan *Trunk-Based Development* untuk fitur cepat dengan pengamanan *Automated Code Review Hooks* berbasis Git hooks dan pipeline CI/CD yang terintegrasi dengan webhook ke server.

Alat yang perlu disiapkan di mesin lokal maupun server antara lain Git versi terbaru, akses ke repository GitHub atau GitLab, environment lokal berbasis Docker untuk simulasi Nginx, Redis, dan MySQL, serta secangkir kopi hangat karena kita akan bermain-main dengan otomatisasi skrip Bash dan konfigurasi pre-commit.

> [!IMPORTANT]
> Pastikan seluruh lead developer dari setiap squad sudah memiliki akses SSH key yang terverifikasi ke repository utama guna menghindari kegagalan otentikasi saat hook otomatis berjalan.

## 2. Peta Jalan Singkat: Apa yang Sedang Kita Rakit
Perjalanan kita dimulai dengan merapikan fondasi strategi branching itu sendiri, meninggalkan Gitflow yang lambat dan beralih ke pendekatan modular yang ramah multi-squad. Setelah struktur branch utama dan penamaan fitur terkunci rapi, kita akan memasang jaring pengaman berupa *Automated Code Review Hooks* di sisi klien dan server. Hooks ini bertindak sebagai satpam digital yang mencegat kode jelek, tidak sesuai standar penulisan, atau berpotensi merusak koneksi database sebelum sempat masuk ke branch integrasi.

Langkah berikutnya, kita menyusun strategi penyelesaian konflik merge secara proaktif. Kita akan mensimulasikan skenario di mana dua squad mengubah baris kode yang sama pada file konfigurasi Nginx atau skrip migrasi MySQL, lalu kita selesaikan menggunakan aturan rebase yang bersih tanpa mengotori commit history.

## 3. Langkah 1: Mempersiapkan Fondasi & Environment
Mari kita mulai dengan mendefinisikan aturan penamaan branch yang konsisten bagi seluruh squad. Di lingkungan multi-squad, kebebasan menamai branch adalah awal dari kekacauan operasional. Kita wajib menggunakan prefiks yang jelas berdasarkan domain squad dan jenis pekerjaan:

```bash
# Format standar penamaan branch untuk semua squad
# squad-name/type/short-description

git checkout -b checkout-squad/feat/redis-session-store
git checkout -b payment-squad/fix/stripe-webhook-timeout
git checkout -b core-squad/refactor/nginx-rate-limit
```

Sekarang, mari kita atur repository lokal agar otomatis melakukan *rebase* alih-alih *merge* saat kita menarik pembaruan dari remote. Ini menjaga linimasa commit tetap linear dan mudah dibaca oleh tool otomatisasi:

```bash
# Mengatur global config agar git pull selalu melakukan rebase
git config --global pull.rebase true

# Verifikasi konfigurasi
git config --get pull.rebase
# Output yang diharapkan: true
```
Perhatikan respons di terminal Anda. Jika bernilai `true`, itu tanda bahwa mesin lokal kita siap menjaga riwayat commit tetap bersih dari branch 'mercusuar' yang membingungkan.

## 4. Langkah 2: Meracik Konfigurasi Inti Tanpa Basa-basi
Fondasi branch sudah berdiri, saatnya memasang *Automated Code Review Hooks* menggunakan Husky dan lint-staged di level pre-commit, serta GitHub Actions / GitLab CI di level server. Kita tidak ingin kode yang mengabaikan standar PSR-12, mengandalkan SQL mentah tanpa prepared statements, atau menyertakan file kredensial `.env` lolos ke server produksi.

Buat file konfigurasi pre-commit hook sederhana di root project `.git/hooks/pre-commit` atau gunakan konfigurasi project-level:

```bash
#!/bin/bash
# File: .git/hooks/pre-commit

echo "[CI/CD Guard] Menjalankan pemeriksaan kualitas kode sebelum commit..."

# Cek apakah ada file .env yang tidak sengaja ter-staging
git diff --cached --name-only | grep -E "\.env$" && {
    echo "[SECURITY ALERT] Ditemukan file .env yang akan di-commit! Batalkan proses."
    exit 1
}

# Jalankan linter PHP / Node sesuai stack Anda
vendor/bin/phpcs --standard=PSR12 app/
if [ $? -ne 0 ]; then
    echo "[ERROR] Standar kode PSR-12 dilanggar. Harap perbaiki sebelum push."
    exit 1
fi

echo "[SUCCESS] Semua pemeriksaan awal lulus. Silakan lanjutkan."
exit 0
```

Jangan lupa berikan izin eksekusi pada file hook tersebut agar sistem operasi dapat menjalankannya secara otomatis:

```bash
chmod +x .git/hooks/pre-commit
```

> [!TIP]
> Integrasikan hook ini dengan penyimpanan cache Redis di environment lokal untuk mempercepat proses pengecekan berulang pada file yang tidak mengalami perubahan.

## 5. Langkah 3: Sentuhan Akhir Keamanan & Optimasi
Di skala multi-squad, bottleneck terbesar sering kali terjadi saat *Pull Request* (PR) menumpuk di penghujung pekan. Untuk mengatasinya, kita terapkan kebijakan *Code Ownership* melalui file `CODEOWNERS` di root repository. Ini memastikan setiap perubahan pada file kritis—seperti konfigurasi Nginx vhost, skema database MySQL, atau kredensial S3—wajib disetujui oleh Tech Lead yang bersangkutan sebelum tombol merge dapat ditekan.

Buat file `CODEOWNERS` di direktori `.github/` atau `.gitlab/`:

```text
# File: .github/CODEOWNERS

# Core infrastructure dan Nginx dikawal oleh SRE Lead
/infra/nginx/                  @sre-lead-team

# Skema database dan migrasi dikawal oleh Database Administrator
/database/migrations/          @dba-team

# Logika pembayaran dikawal oleh Payment Squad Lead
/app/Services/Payment/         @payment-lead
```

Dengan aturan ini, sistem secara otomatis akan menandai reviewer yang tepat begitu seorang developer membuat PR, memangkas waktu tunggu birokrasi koordinasi antar squad.

## 6. Tes Rasa: Memastikan Semuanya Berjalan Sempurna
Saatnya menguji racikan kita di lapangan. Mari kita simulasi alur kerja ketika dua developer dari squad berbeda mengubah file yang sama secara bersamaan. Buka terminal Anda, buat branch fitur baru, lakukan perubahan pada file konfigurasi, dan coba lakukan push:

```bash
# Simulasi pekerjaan squad
git checkout -b payment-squad/feat/gateway-update
echo "// Konfigurasi gateway baru" >> app/config.js
git add app/config.js
git commit -m "feat(payment): update gateway endpoint"

# Lakukan push ke remote
git push origin payment-squad/feat/gateway-update
```

Perhatikan respons dari server dan hook pre-commit yang baru saja kita pasang. Jika hook berjalan tanpa error dan PR berhasil terbuka dengan reviewer otomatis dari file `CODEOWNERS`, selamat! Arsitektur kolaborasi multi-squad Anda kini jauh lebih tahan banting terhadap konflik destruktif.

> [!WARNING]
> Jika Anda mendapati konflik merge yang masif akibat dua squad mengubah baris yang sama, jangan gunakan fitur `git merge` sembarangan. Gunakan `git rebase origin/main` untuk menyusun ulang commit Anda di atas kode terbaru secara rapi.

## 7. Pertolongan Pertama: Jika Terjadi Kendala Kecil
Di lapangan, error kecil adalah sahabat karib engineer. Jika Anda mendapati hook pre-commit menolak commit padahal Anda merasa kode sudah benar, periksa kembali izin eksekusi file hook dengan `ls -l .git/hooks/pre-commit`. Sering kali permission ter-reset saat berpindah sistem operasi atau clone ulang.

Jika pipeline CI/CD di server gagal karena masalah koneksi database saat menjalankan automated test, pastikan service MySQL dan Redis di container Docker lokal atau server staging Anda sudah berjalan stabil dan merespons port dengan benar:

```bash
# Cek status service database dan cache
systemctl status mysql redis-server
# Atau jika menggunakan Docker:
docker compose ps
```
Dengan fondasi Git branching yang terstruktur rapi, hooks otomatis yang ketat, dan pembagian ownership yang jelas, puluhan squad kini dapat bekerja secara paralel di dalam satu repository besar tanpa saling menginjak kaki.