Git Workflow: GitHub Flow, Git Flow, dan Cara Memilih yang Tepat

Branching di Git sangat fleksibel — tidak ada aturan bawaan tentang bagaimana harus digunakan. Karena itulah komunitas developer menciptakan berbagai workflow (alur kerja) yang menjadi konvensi bersama dalam tim. Dua yang paling populer adalah GitHub Flow dan Git Flow. Memilih workflow yang tepat bisa membuat kolaborasi tim jauh lebih mulus.

Mengapa Butuh Workflow?

Tanpa konvensi yang disepakati, setiap developer bisa bekerja dengan cara berbeda — ada yang push langsung ke main, ada yang buat branch sembarangan, tidak ada yang tahu kapan kode siap di-deploy. Workflow memberikan aturan main yang jelas tentang:

Branch mana yang boleh ada
Bagaimana alur merge dari branch ke branch
Kapan kode boleh di-deploy ke production

GitHub Flow — Simpel dan Cocok untuk CD

GitHub Flow adalah workflow yang sangat sederhana. Diciptakan oleh GitHub untuk tim yang melakukan Continuous Deployment (deploy ke production sangat sering, bahkan beberapa kali sehari).

Aturan GitHub Flow

main selalu dalam kondisi deployable (siap production)
Semua pekerjaan dilakukan di feature branch dari main
Branch didorong ke remote secara reguler untuk backup dan visibilitas
Buat Pull Request saat siap untuk review atau diskusi
Review dan approval sebelum merge
Deploy setelah merge ke main

Diagram GitHub Flow

main:   ─────────────────────────────────────────────────→
                 ↑ merge PR    ↑ merge PR    ↑ merge PR
feature-a:    ───────────
feature-b:          ────────────────
hotfix:                      ───────

Workflow Harian dengan GitHub Flow

# 1. Update main
git switch main
git pull origin main

# 2. Buat branch dari main
git switch -c feature/tambah-notifikasi

# 3. Kerjakan, commit secara rutin
git commit -m "feat: tambah service notifikasi email"
git commit -m "feat: tambah template email registrasi"
git commit -m "test: tambah unit test notifikasi"

# 4. Push ke remote secara reguler
git push -u origin feature/tambah-notifikasi

# 5. Buka Pull Request di GitHub
# 6. Review dan diskusi
# 7. Merge ke main → deploy otomatis via CI/CD
# 8. Hapus branch
git branch -d feature/tambah-notifikasi
git push origin --delete feature/tambah-notifikasi

Kapan GitHub Flow Cocok?

Tim kecil hingga menengah
Produk web/SaaS yang deploy sangat sering
Tim yang sudah punya CI/CD yang solid
Startup yang butuh move fast

Git Flow — Terstruktur untuk Rilis Terjadwal

Git Flow dirancang oleh Vincent Driessen pada 2010 untuk proyek dengan siklus rilis yang lebih formal — versi yang di-release pada jadwal tertentu, bukan continuous deployment.

Branch dalam Git Flow

main       — kode production (setiap commit = satu versi rilis)
develop    — branch integrasi development
feature/*  — fitur baru (dari develop, kembali ke develop)
release/*  — persiapan rilis (dari develop, merge ke main + develop)
hotfix/*   — perbaikan darurat production (dari main, merge ke main + develop)

Diagram Git Flow

main:     ●──────────────────────●──────────────●──→
          │(v1.0)                │(v1.1)         │(v1.1.1)
          │           merge ↗    │     merge ↗   │ merge ↗
develop:  ●──────────────────────●───────────────●──→
          │↑ merge feature       ↑ merge feature
feature:  └─────────────┘  └─────────────┘
                 ↑ release branch
release:         └──────────────┘
hotfix:                          ●──────●
                                 └──────┘ ↗ merge ke main + develop

Perintah Git Flow

Kamu bisa menggunakan library git-flow untuk shortcut:

# Install git-flow
# macOS: brew install git-flow-avh
# Ubuntu: apt install git-flow

# Inisialisasi di repository
git flow init

# Mulai fitur baru
git flow feature start nama-fitur
# = git switch -c feature/nama-fitur develop

# Selesaikan fitur (merge ke develop, hapus branch)
git flow feature finish nama-fitur

# Publish fitur ke remote
git flow feature publish nama-fitur

# Mulai release
git flow release start 1.2.0
# = git switch -c release/1.2.0 develop

# Selesaikan release (merge ke main + develop, buat tag)
git flow release finish 1.2.0

# Mulai hotfix
git flow hotfix start perbaikan-login
# = git switch -c hotfix/perbaikan-login main

# Selesaikan hotfix
git flow hotfix finish perbaikan-login

Tanpa Library git-flow (Manual)

# Fitur baru
git switch -c feature/dark-mode develop
# ... kerjakan ...
git switch develop
git merge --no-ff feature/dark-mode
git branch -d feature/dark-mode

# Release
git switch -c release/1.2.0 develop
# ... bump version, update changelog ...
git switch main
git merge --no-ff release/1.2.0
git tag -a v1.2.0 -m "Rilis versi 1.2.0"
git switch develop
git merge --no-ff release/1.2.0
git branch -d release/1.2.0

# Hotfix
git switch -c hotfix/login-error main
# ... perbaiki bug ...
git switch main
git merge --no-ff hotfix/login-error
git tag -a v1.1.1 -m "Hotfix: perbaiki error login"
git switch develop
git merge --no-ff hotfix/login-error
git branch -d hotfix/login-error

Kapan Git Flow Cocok?

Aplikasi dengan versi rilis yang terjadwal (bulanan, quarterly)
Mobile app (App Store review butuh waktu — tidak bisa CD)
Software enterprise dengan SLA dan change management ketat
Library/SDK yang punya multiple version aktif

Perbandingan GitHub Flow vs Git Flow

Aspek	GitHub Flow	Git Flow
Kompleksitas	Rendah	Tinggi
Jumlah branch permanent	1 (main)	2 (main + develop)
Cocok untuk	CD, web app	Rilis terjadwal
Kecepatan delivery	Sangat cepat	Lebih terstruktur
Overhead	Minimal	Lebih banyak
Parallel release	Tidak	Ya

Trunk-Based Development — Alternatif Modern

Trunk-Based Development (TBD) adalah pendekatan yang lebih ekstrem dari GitHub Flow. Semua developer commit langsung ke main (trunk) atau ke short-lived branch yang hidup maksimal 1-2 hari.

main:   ─●─●─●─●─●─●─●─●─●─→
          ↑ ↑ ↑ ↑ commit langsung atau branch sangat pendek

TBD membutuhkan:

Feature flags untuk sembunyikan fitur yang belum siap
CI yang sangat kuat — test harus cepat dan reliable
Tim yang disiplin dengan commit kecil dan sering

Digunakan oleh Google, Facebook, dan perusahaan tech besar.

Rekomendasi

Startup / Tim kecil / Web app: GitHub Flow
Produk dengan jadwal rilis: Git Flow
Tim mature dengan CI solid: Trunk-Based Development
Jangan overthink: GitHub Flow simpel dan cukup untuk 90% kasus

Kesimpulan

Tidak ada workflow yang sempurna untuk semua situasi. Yang terpenting adalah tim menyepakati satu workflow, mendokumentasikannya, dan menjalankannya secara konsisten. Di artikel berikutnya, kita bahas strategi pengelolaan commit yang baik — conventional commits dan cara menulis histori Git yang mudah dibaca.