Gitflow

Gitflow #

Dalam pengembangan software modern, Git bukan sekadar alat version control, tetapi fondasi utama kolaborasi tim. Namun, Git tanpa aturan workflow sering berujung pada konflik branch, commit yang berantakan, dan proses rilis yang kacau. Di sinilah Gitflow hadir sebagai salah satu workflow paling populer dan terstruktur.

Artikel ini akan membahas:

  • Apa itu Gitflow
  • Konsep dan struktur branch Gitflow
  • Alur kerja Gitflow secara end-to-end
  • Kelebihan dan kekurangan Gitflow
  • Best practices Gitflow di dunia nyata
  • Kapan Gitflow cocok dan kapan tidak

Apa Itu Gitflow? #

Gitflow adalah branching model yang diperkenalkan oleh Vincent Driessen untuk mengelola siklus hidup pengembangan software secara rapi dan terprediksi.

Gitflow memisahkan:

  • Pengembangan fitur
  • Perbaikan bug
  • Persiapan rilis
  • Maintenance produksi

ke dalam branch yang jelas dan memiliki tujuan spesifik.

Intinya: Gitflow = disiplin struktur + alur rilis yang konsisten.

Struktur Branch dalam Gitflow #

Gitflow memiliki dua branch utama permanen dan beberapa branch temporer.

1️⃣ main (atau master) #

  • Berisi kode produksi
  • Setiap commit di main merepresentasikan versi rilis
  • Biasanya diberi tag versi (v1.0.0, v1.1.0)

❗ Tidak boleh commit langsung ke main

2️⃣ develop #

  • Branch utama untuk development aktif
  • Semua fitur baru akan digabung ke sini
  • Menjadi dasar pembuatan branch release

📌 Anggap develop sebagai next production

3️⃣ feature/* #

Digunakan untuk mengembangkan fitur baru.

Contoh:

feature/login-google
feature/payment-integration

Karakteristik:

  • Dibuat dari develop
  • Digabung kembali ke develop
  • Dihapus setelah selesai

4️⃣ release/* #

Digunakan untuk persiapan rilis.

Contoh:

release/1.2.0

Fungsi:

  • Finalisasi fitur
  • Bug fixing ringan
  • Update versi & changelog

Setelah selesai:

  • Merge ke main
  • Merge kembali ke develop
  • Beri tag versi

5️⃣ hotfix/* #

Digunakan untuk perbaikan bug kritikal di production.

Contoh:

hotfix/1.2.1

Karakteristik:

  • Dibuat dari main
  • Langsung memperbaiki issue production
  • Merge ke main dan develop

Diagram Alur Gitflow #

main ───────────────●─────────────●────────────
                     \            /
                      \ hotfix   /
                       ●────────●

        develop ───●────●────●────●────●──────
                    \    \         /
                     \    feature /
                      ●──────────●
                           \
                            release
                             ●────●

Alur Kerja Gitflow (Step-by-Step) #

🧩 1. Mengembangkan Fitur Baru #

  1. Buat branch dari develop

    git checkout -b feature/user-profile develop

  2. Kerjakan fitur

  3. Merge ke develop

  4. Hapus branch feature

🚀 2. Menyiapkan Rilis #

  1. Buat branch rilis dari develop

    git checkout -b release/1.3.0 develop

  2. Fix bug minor

  3. Update versi & dokumentasi

  4. Merge ke main dan develop

  5. Tag rilis

🚑 3. Hotfix Production #

  1. Buat branch dari main

    git checkout -b hotfix/1.3.1 main

  2. Fix bug kritikal

  3. Merge ke main dan develop

  4. Tag patch version

Kelebihan Gitflow #

✅ Struktur branch sangat jelas ✅ Cocok untuk tim besar ✅ Rilis terkontrol dan terprediksi ✅ Mendukung multiple version maintenance

Kekurangan Gitflow #

❌ Kompleks untuk tim kecil ❌ Terlalu berat untuk CI/CD cepat ❌ Banyak merge = overhead ❌ Tidak ideal untuk deployment harian

Gitflow vs Workflow Lain #

WorkflowCocok UntukCatatan
GitflowEnterprise, release-basedStruktur kuat
GitHub FlowStartup, CI/CD cepatSimple
Trunk-BasedHigh-frequency deployDisiplin tinggi

Best Practices Gitflow #

✅ 1. Lindungi Branch Penting #

  • Gunakan branch protection
  • Wajib PR & review
  • Larang direct push ke main & develop

✅ 2. Gunakan Semantic Versioning #

MAJOR.MINOR.PATCH

Contoh:

  • 1.2.0 → fitur baru
  • 1.2.1 → bugfix

✅ 3. Feature Branch Harus Kecil #

  • Hindari feature terlalu lama
  • Break down fitur besar

✅ 4. Selalu Merge Balik ke Develop #

Terutama untuk:

  • hotfix
  • release

Agar tidak terjadi version drift.

✅ 5. Automasi dengan CI/CD #

  • Test otomatis di feature dan develop
  • Deploy otomatis dari main
  • Tag-based deployment

✅ 6. Konsisten Naming Convention #

feature/<scope>
release/<version>
hotfix/<version>

Kapan Gitflow Cocok Digunakan? #

Gitflow cocok jika:

  • Tim cukup besar
  • Release berbasis versi
  • Maintenance banyak versi
  • Stabilitas lebih penting dari kecepatan

❌ Hindari Gitflow jika:

  • Startup early-stage
  • Continuous deployment harian
  • Tim < 5 orang

Deployment ke Production: Tag vs main/master #

Ini adalah salah satu area yang paling sering menimbulkan perdebatan, terutama bagi engineer yang pernah bekerja di perusahaan dengan workflow berbeda.

Banyak engineer (dan bahkan perusahaan) melakukan deployment langsung dari branch main/master. Praktik ini tidak selalu salah, tetapi berbeda konteks dengan Gitflow.

Prinsip Dasar Gitflow #

Dalam Gitflow:

  • main/master merepresentasikan history production
  • Tag merepresentasikan versi rilis yang dideploy

Artinya: production seharusnya dideploy dari TAG, bukan sekadar branch.

Kenapa Bukan Langsung dari main/master? #

Branch bersifat mutable:

  • Commit bisa ditambah
  • History bisa berubah (revert, hotfix, merge ulang)

Sementara tag bersifat immutable:

  • Tidak berubah
  • Bisa di-deploy ulang kapan pun
  • Aman untuk audit dan rollback

Contoh:

main
 ├─ commit A  (tag: v1.3.0)  ✅ deployed
 ├─ commit B  (tag: v1.4.0)  ✅ deployed
 └─ commit C  (tag: v1.4.1)  ✅ deployed

Yang dideploy ke production adalah:

v1.4.1

Bukan:

main@HEAD

Workflow Gitflow yang Benar untuk Production #

release/1.4.0
      ↓ merge
main ──●── tag v1.4.0 ──▶ DEPLOY PROD

Langkah ideal:

  1. Merge release/* ke main
  2. Buat annotated tag (v1.4.0)
  3. CI/CD deploy berdasarkan tag

Kenapa Banyak Company Deploy dari main/master? #

Biasanya karena mereka:

  • Tidak pakai Gitflow murni
  • Menggunakan GitHub Flow atau Trunk-Based Development
  • Fokus ke continuous deployment

Dalam konteks itu:

  • main = production-ready setiap saat
  • Setiap merge = kandidat deploy

⚠️ Masalah muncul ketika:

  • Mengaku pakai Gitflow
  • Tapi deploy langsung dari main

Ini menciptakan false sense of Gitflow.

Trigger deployment berdasarkan tag:

on:
  push:
    tags:
      - 'v*.*.*'

Keuntungan:

  • Deploy eksplisit (bukan implicit)
  • Rollback jelas
  • Traceability tinggi

Ringkasan Cepat #

PraktikCocok untuk Gitflow?Aman untuk Prod
Deploy dari develop❌❌
Deploy dari main tanpa tag⚠️⚠️
Deploy dari main + tag✅✅
Deploy dari tag saja🔥🔥

Kesimpulan #

Gitflow memberikan kontrol dan stabilitas, tetapi hanya jika dijalankan secara konsisten.

Jika Anda pernah berada di company yang deploy langsung dari main/master, kemungkinan besar:

  • Mereka tidak sepenuhnya menggunakan Gitflow, atau
  • Mereka sengaja memilih workflow lain

Gitflow bukan soal banyaknya branch, tapi soal disiplin rilis dan versi.

Pilih workflow berdasarkan:

  • Ukuran tim
  • Frekuensi rilis
  • Kebutuhan audit & rollback

Bukan sekadar ikut tren.

About | Author | Content Scope | Editorial Policy | Privacy Policy | Disclaimer | Contact