# Strategi Git Branching GitFlow vs Trunk-Based Development di Tim Skala Besar

> Diterbitkan oleh Literally Web ID pada 21 Oct 2026
> Sumber: https://literally.web.id/articles/strategi-git-branching-gitflow-vs-trunk-based-development-di-tim-skala-besar

---

Dalam 15 menit ke depan, kita akan merakit strategi manajemen branch yang mengubah nasib deployment tim Anda dari proses yang menegangkan menjadi rutinitas harian yang membosankan—dalam artian yang paling membahagiakan bagi seorang Principal Engineer. Bayangkan Anda sedang berdiri di dapur infrastruktur skala besar, memegang kendali atas ekosistem web modern yang didukung oleh Go dan Node.js di backend, Nginx serta Cloudflare di edge, memutar Redis untuk caching kilat, dan bersandar pada MySQL untuk ketahanan data. Masalah klasik yang sering saya temui di lapangan bukanlah kodenya yang jelek, melainkan antrean pull request yang menumpuk bagaikan piring kotor di wastafel karena kita terlalu lama terjebak dalam labirin GitFlow.

## 1. Menu Kita Hari Ini & Alat yang Perlu Disiapkan

Kita tidak akan membuang waktu dengan definisi teoretis klise tentang apa itu Git. Langsung saja, bahan-bahan dapur yang harus Anda siapkan di terminal workstation Anda meliputi:
- Git CLI versi terbaru yang terpasang rapi.
- Akses repository remote (GitHub/GitLab/Bitbucket) dengan integrasi webhook CI/CD.
- Pipeline runner (GitHub Actions atau GitLab CI) yang terhubung ke server staging Nginx + PHP-FPM / Node.js.
- Feature flag service (kita bisa menggunakan open-source tools seperti Unleash atau implementasi Redis-backed sederhana).

Perhatikan bagaimana kita akan merombak total kebiasaan lama. Jika biasanya tim Anda membuat branch `feature/`, `release/`, `hotfix/`, dan `develop` secara bersamaan hingga membuat pusing kepala saat proses *merge conflict* melanda, hari ini kita membuang kerumitan itu dan beralih ke kesederhanaan Trunk-Based Development yang dikawinkan dengan Feature Flags.

## 2. Peta Jalan Singkat: Apa yang Sedang Kita Rakit

> [!TIP]
> Jangan bayangkan ini sebagai perubahan radikal yang merusak sistem yang ada. Kita akan melakukan transisi secara bertahap.

Alur kerja kita dimulai dari bagaimana developer menulis kode kecil langsung ke branch utama (`main`), menguji otomatisasinya lewat pipeline CI, mengamankan rilis fitur besar menggunakan saklar Feature Flag di Redis, hingga memantau metrik performa rilis melalui log Nginx dan APM. Mari kita mulai racikannya dari fondasi environment.

## 3. Langkah 1: Mempersiapkan Fondasi & Environment

Sebelum menyentuh kode, pastikan pipeline CI/CD Anda di server siap merespons commit sekecil apa pun ke trunk branch. Buat sebuah file konfigurasi GitHub Actions sederhana di `.github/workflows/ci.yml` untuk memastikan setiap push diverifikasi ketat oleh lintern dan unit test.

```yaml
name: Fast CI Pipeline

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Set up Go
        uses: actions/setup-go@v5
        with:
          go-version: '1.22'
      - name: Run Tests
        run: go test -v ./...
```

> [!IMPORTANT]
> Perhatikan respons dari terminal Anda saat menjalankan perintah `git push origin main`. Jika pipeline hijau dalam waktu kurang dari 3 menit, itu adalah tanda bahwa service kita sudah mulai merespons dengan sehat.

## 4. Langkah 2: Meracik Konfigurasi Inti Tanpa Basa-basi

Dalam Trunk-Based Development, kita meninggalkan branch `develop` yang gemuk. Sebagai gantinya, semua developer melakukan *short-lived feature branches* yang umurnya tidak lebih dari 24 jam, lalu langsung di-*merge* ke `main`. Agar server Nginx di production tidak menyajikan kode yang setengah matang saat fitur baru masuk, kita membungkus logika fitur tersebut dengan Feature Flag.

Mari lihat implementasi sederhana pengecekan feature flag berbasis Redis menggunakan Go di backend web kita:

```go
package main

import (
	"context"
	"fmt"
	"github.com/redis/go-redis/v9"
)

var ctx = context.Background()

func IsFeatureEnabled(rdb *redis.Client, featureName string) bool {
	val, err := rdb.Get(ctx, "feature:"+featureName).Result()
	if err != nil {
		// Default ke false jika Redis error atau flag belum diset
		return false
	}
	return val == "true"
}

func main() {
	rdb := redis.NewClient(&redis.Options{
		Addr: "localhost:6379",
	})

	if IsFeatureEnabled(rdb, "new_checkout_flow") {
		fmt.Println("Menggunakan Checkout Versi Baru (Trunk-Based + Flag)")
	} else {
		fmt.Println("Menggunakan Checkout Legacy Standard")
	}
}
```

Dengan cara ini, meskipun kode fitur baru sudah berada di production branch (`main`), pengguna akhir belum akan melihatnya sampai kita membalikkan nilai di Redis menjadi `true` melalui panel admin atau CLI.

## 5. Langkah 3: Sentuhan Akhir Keamanan & Optimasi

Kecepatan rilis tanpa pengamanan infrastruktur adalah bunuh diri. Pastikan WAF dan reverse proxy Anda dikonfigurasi dengan benar untuk menangani lonjakan trafik mendadak pasca-deployment. Di Nginx, pastikan Anda mengatur header caching dengan bijak agar aset statis terdistribusi sempurna lewat Cloudflare CDN:

```nginx
server {
    listen 80;
    server_name api.domain.com;

    location /static/ {
        alias /var/www/html/static/;
        expires 30d;
        add_header Cache-Control "public, no-transform";
    }

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}
```

## 6. Tes Rasa: Memastikan Semuanya Berjalan Sempurna

Saatnya melakukan verifikasi kilat. Jalankan skrip pengujian beban ringan menggunakan `curl` atau Apache Bench untuk memastikan endpoint backend Anda merespons dengan latensi di bawah 50 milidetik:

```bash
curl -I https://api.domain.com/healthz
```

Jika respons mengembalikan `HTTP/2 200 OK` dengan header Cache-Control yang sesuai, racikan infrastruktur dan alur kerja Anda telah sukses menyatu tanpa friksi.

## 7. Pertolongan Pertama: Jika Terjadi Kendala Kecil

Jika tiba-tiba terjadi error 502 Bad Gateway setelah merge code baru ke trunk, jangan panik. Cek log error PHP-FPM atau supervisor backend Go Anda:

```bash
sudo tail -n 50 /var/log/nginx/error.log
```

Biasanya, ini terjadi karena ada variabel environment baru yang belum di-set di server. Cukup perbarui file `.env`, restart service dengan `sudo systemctl restart nginx`, dan sistem Anda akan kembali normal dalam hitungan detik. Selamat menikmati siklus rilis yang cepat dan menyenangkan!