Waktu pertama kali kerja di tim yang lebih dari 3 orang, saya langsung kena masalah branch conflict setiap hari. Ada yang push ke main, ada yang bikin branch namanya asal-asalan, dan merge conflict jadi rutinitas pagi. Setelah coba beberapa strategi, barulah saya paham bahwa pilihan git workflow itu ngaruh banget ke produktivitas tim.

Di artikel ini, saya mau share pengalaman pakai tiga workflow paling populer: Git Flow, GitHub Flow, dan Trunk-Based Development. Masing-masing punya kelebihan, dan pilihan yang tepat tergantung jenis project dan ukuran tim kamu.

Kenapa Git Workflow Itu Penting

Bayangkan kamu kerja bareng 5 orang developer. Tanpa aturan yang jelas soal branching, setiap orang punya cara sendiri. Ada yang langsung commit ke main, ada yang bikin 20 branch tapi nggak pernah merge, ada yang force push dan menghilangkan kerja orang lain.

Git workflow itu basically aturan main untuk tim kamu. Siapa yang boleh merge ke main? Branch apa saja yang wajib ada? Kapan saatnya release? Semua ini diatur oleh workflow yang kamu pilih.

• Konsistensi: Semua orang tahu harus bikin branch dari mana dan merge ke mana
• Code review: Ada kesempatan untuk review sebelum code masuk ke production
• Stability: Main branch selalu dalam kondisi yang bisa di-deploy
• Rollback: Kalau ada bug, gampang balik ke commit sebelumnya

Git Flow - Si Tertua yang Masih Eksis

Git Flow dipopulerkan oleh Vincent Driessen tahun 2010. Workflow ini punya branch yang cukup banyak dan aturan yang ketat soal kapan setiap branch boleh dibuat dan di-merge.

Branch utama di Git Flow:

• main/master: Branch production, hanya berisi code yang sudah di-release
• develop: Branch integrasi, tempat semua fitur baru dikumpulkan
• feature/*: Branch untuk develop fitur baru, dibuat dari develop
• release/*: Branch persiapan release, dibuat dari develop
• hotfix/*: Branch untuk fix urgent di production, dibuat dari main

Cara pakai Git Flow:

# Install git-flow (Ubuntu/Debian)
sudo apt install git-flow

# Inisialisasi di repo yang sudah ada
git flow init

# Bikin fitur baru
git flow feature start user-authentication

# Selesai develop fitur, merge ke develop
git flow feature finish user-authentication

# Persiapan release
git flow release start v2.1.0

# Release selesai, merge ke main dan develop
git flow release finish v2.1.0

# Hotfix urgent
git flow hotfix start critical-login-bug
git flow hotfix finish critical-login-bug

Contoh manual tanpa git-flow CLI:

# Mulai dari develop
git checkout develop
git pull origin develop

# Bikin feature branch
git checkout -b feature/payment-gateway

# Kerja di feature branch...
git add .
git commit -m "feat: integrate Midtrans payment"

# Merge balik ke develop
git checkout develop
git merge --no-ff feature/payment-gateway
git push origin develop

# Hapus feature branch
git branch -d feature/payment-gateway

Kapan Cocok Pakai Git Flow

• Project dengan release cycle terjadwal: misalnya release tiap bulan atau tiap quarter
• Tim besar (10+ developer): butuh koordinasi yang ketat
• Project enterprise: yang butuh audit trail dan approval process
• Mobile apps: yang release-nya ke App Store/Play Store secara terjadwal

Kelebihan Git Flow:

• Struktur sangat jelas, newbie pun gampang ngikutin
• Cocok untuk project yang butuh maintenance banyak versi sekaligus
• Hotfix process terpisah dari development biasa

Kekurangan Git Flow:

• Banyak branch = banyak merge conflict
• Release branch bikin proses deploy jadi lama
• Overkill untuk project kecil atau startup
• develop branch sering jadi bottleneck

GitHub Flow - Simpel dan Langsung

GitHub Flow jauh lebih simple dibanding Git Flow. Hanya ada satu branch utama (main) dan feature branches. Kalau fitur sudah siap, bikin Pull Request, review, merge, deploy. Gitu aja.

# Selalu mulai dari main
git checkout main
git pull origin main

# Bikin branch baru
git checkout -b add-search-feature

# Commit perubahan
git add .
git commit -m "feat: add full-text search to product page"

# Push ke remote
git push origin add-search-feature

# Buka Pull Request di GitHub
# Setelah review dan approve, merge ke main
# Deploy otomatis dari main

Aturan GitHub Flow:

1. Apapun yang ada di main harus bisa di-deploy
2. Fitur baru selalu mulai dari branch yang dibuat dari main
3. Commit ke remote branch secara berkala
4. Buka Pull Request kalau butuh review atau siap merge
5. Setelah review, merge ke main dan deploy

Contoh workflow di team:

# Developer A: bikin fitur baru
git checkout main && git pull
git checkout -b feature/user-dashboard
# ... kerja ...
git push origin feature/user-dashboard
# Buka PR di GitHub

# Developer B: review PR
git fetch origin
git checkout feature/user-dashboard
# Review code di IDE atau di GitHub UI
# Kasih comment atau approve

# Developer A: merge setelah approve
# Klik "Merge pull request" di GitHub
# Branch otomatis terhapus

Kapan Cocok Pakai GitHub Flow

• Web apps yang deploy terus: CI/CD pipeline, deploy ke production tiap hari
• Tim kecil-sedang (2-10 orang): nggak butuh koordinasi yang ribet
• Startup: yang butuh ship fast dan iterate cepat
• Open source projects: contributor bikin fork, bikin PR

Kelebihan GitHub Flow:

• Sangat simple, gampang dipelajari
• Deploy cepat karena main selalu ready
• PR-based review bikin code quality lebih baik
• Branch lifecycle pendek, merge conflict minim

Kekurangan GitHub Flow:

• Nggak cocok kalau butuh maintain banyak versi
• Tidak ada mekanisme hotfix terpisah
• Harus punya CI/CD yang solid, kalau nggak main branch bisa broken

Trunk-Based Development - Ship Fast

Trunk-Based Development (TBD) adalah workflow di mana semua developer commit langsung ke satu branch utama (trunk/main). Feature branches kalau ada pun sangat pendek, maksimal 1-2 hari.

Konsep utama:

• Short-lived branches: branch hidup maksimal 2 hari
• Feature flags: fitur yang belum selesai disembunyikan pakai flag
• Continuous integration: setiap commit langsung di-test otomatis
• Trunk selalu deployable: broken code nggak boleh sampai ke trunk

# Developer langsung commit ke main
git checkout main
git pull origin main
# ... kerja ...
git add .
git commit -m "feat: add cart sidebar component"
git push origin main

# Atau pakai branch pendek
git checkout -b quick-fix-header
# ... fix ...
git checkout main
git merge quick-fix-header
git push origin main

Feature flags di practice:

// config/feature-flags.js
const featureFlags = {
    newCheckoutFlow: process.env.FF_NEW_CHECKOUT === 'true',
    darkMode: process.env.FF_DARK_MODE === 'true',
    betaSearch: false, // belum siap
};

// Di component
if (featureFlags.newCheckoutFlow) {
    renderNewCheckout();
} else {
    renderOldCheckout();
}

<?php
// Feature flag di PHP
class FeatureFlags {
    public static function isEnabled(string $flag): bool {
        $flags = [
            'new_dashboard' => env('FF_NEW_DASHBOARD', false),
            'ai_search' => env('FF_AI_SEARCH', false),
        ];
        return $flags[$flag] ?? false;
    }
}

// Di controller
if (FeatureFlags::isEnabled('new_dashboard')) {
    return view('dashboard/v2');
}
return view('dashboard/v1');

Kapan Cocok Pakai Trunk-Based Development

• Tim yang mature: sudah punya CI/CD pipeline yang solid
• Deploy frequency tinggi: beberapa kali sehari
• Tim kecil yang highly coordinated: komunikasi lancar
• Microservices: service kecil yang bisa di-deploy independen

Kelebihan Trunk-Based:

• Deploy paling cepat di antara ketiga workflow
• Merge conflict hampir nggak ada karena branch sangat pendek
• Code selalu terintegrasi, nggak ada "branch hell"
• Force developer untuk bikin commit yang kecil dan sering

Kekurangan Trunk-Based:

• Butuh CI/CD yang sangat reliable
• Feature flags menambah complexity di codebase
• Nggak cocok untuk tim yang masih baru dengan Git
• Risiko broken production kalau testing nggak solid

Perbandingan Langsung

Praktik Terbaik untuk Semua Workflow

Apapun workflow yang kamu pilih, ada beberapa best practice yang wajib diterapkan:

1. Commit message yang jelas

# BAD
git commit -m "fix"
git commit -m "update"
git commit -m "changes"

# GOOD - pakai conventional commits
git commit -m "feat: add user registration with email verification"
git commit -m "fix: resolve null pointer on empty cart checkout"
git commit -m "refactor: extract payment logic to service class"
git commit -m "docs: update API endpoint documentation"

2. Branch naming convention

# Format: type/short-description
feature/user-auth
feature/payment-integration
bugfix/login-redirect
hotfix/security-patch-xss
chore/update-dependencies
docs/api-documentation

3. Lindungi main branch

# Di GitHub: Settings > Branches > Branch protection rules
# Checklist:
# - Require pull request reviews before merging
# - Require status checks to pass (CI must be green)
# - Require branches to be up to date before merging
# - Include administrators (jangan bypass aturan sendiri)

4. Rebase vs Merge

# Merge: commit history bercabang
git checkout main
git merge feature-branch
# Result: commit history bercabang, ada merge commit

# Rebase: commit history linear
git checkout feature-branch
git rebase main
git checkout main
git merge feature-branch
# Result: commit history linear, lebih rapi

# Interactive rebase untuk clean up commit
git rebase -i HEAD~3
# Bisa squash, reword, atau drop commit

5. Git bisect untuk cari bug

# Mulai bisect
git bisect start

# Tandai commit yang broken
git bisect bad

# Tandai commit yang masih bagus
git bisect good v2.0.0

# Git akan checkout commit di tengah
# Test, lalu tandai sebagai good atau bad
git bisect good  # atau
git bisect bad

# Ulangi sampai ketemu commit yang bikin bug
# Git kasih output:
# abc1234 is the first bad commit

# Selesai
git bisect reset

Workflow untuk Tim di Indonesia

Berdasarkan pengalaman saya, kebanyakan tim dev di Indonesia pakai GitHub Flow karena:

• TIM kebanyakan 3-10 orang, cocok dengan GitHub Flow
• Deploy ke VPS atau cloud langsung, nggak perlu release cycle yang ribet
• Client sering minta perubahan mendadak, butuh ship fast
• Git Flow terlalu berat untuk project freelance atau agency

Kalau kamu kerja di startup atau agency, mulai dengan GitHub Flow. Kalau sudah matang dan punya CI/CD yang solid, baru pertimbangkan Trunk-Based. Git Flow lebih cocok untuk perusahaan besar yang punya QA team dan release schedule.

Kesimpulan

Tidak ada workflow yang paling benar. Yang paling penting adalah konsistensi. Lebih baik pakai GitHub Flow secara konsisten daripada pakai Git Flow tapi nggak pernah ngikutin aturannya. Pilih workflow yang sesuai dengan ukuran tim, jenis project, dan culture kerja tim kamu.

Kalau baru mulai, saran saya: pakai GitHub Flow dulu. Simple, gampang dipelajari, dan cocok untuk mayoritas project web development. Setelah tim makin besar dan proses makin matang, baru evaluate apakah perlu pindah ke Git Flow atau Trunk-Based Development.