Mengenal GitFlow

1. Apa itu GitFlow?

GitFlow adalah model branching workflow untuk Git yang diperkenalkan oleh Vincent Driessen (2010). Tujuannya: menyediakan pola standar untuk pengembangan fitur, persiapan rilis, hotfix, dan pemeliharaan sehingga tim besar bisa bekerja secara paralel tanpa kacau.

GitFlow bukan alat, melainkan konvensi (biasa juga ada script helper bernama git-flow), yang mendefinisikan cabang-cabang utama dan bagaimana mereka berinteraksi.

---

2. Cabang-cabang pada GitFlow

• main (atau master) Berisi kode yang selalu siap produksi. Hanya commit yang sudah rilis (biasanya di-tag) yang ada di sini.

• develop Tempat integrasi semua fitur. Menjadi cikal bakal release berikutnya. Setelah stabil, develop di-merge ke main lewat release branch.

• feature/* Cabang untuk mengerjakan fitur baru. Dibuat dari develop dan di-merge kembali ke develop. Nama contoh: feature/auth-api.

• release/* Dibuat dari develop untuk menyiapkan rilis (bugfix minor, bump version, dokumen). Setelah siap, release di-merge ke main (untuk rilis) dan kembali ke develop (untuk sinkron).

• hotfix/* Dibuat dari main untuk memperbaiki bug yang perlu di-patch segera di produksi. Setelah selesai, di-merge ke main(dan biasanya di-tag), serta di-merge kembali ke develop.

Skema ringkas (visual ASCII):

main ---o------o---------o---------- (rilis)
         \        \        \
develop ---o---o---o---o---o---o---- (integrasi fitur)
          \   \       /
feature/foo  feature/bar

---

3. Kapan GitFlow cocok — dan kapan tidak?

Cocok untuk:

• Tim medium–besar (lebih dari 3 orang).

• Rilis yang terjadwal (release cycle terpisah dari deploy).

• Produk dengan lifecycle rilis (semver, rilis stabil ke production).

• Ketika ingin kontrol eksplicit antara development dan production branch.

Kurang cocok untuk:

• Tim kecil (1–3 orang) atau proyek yang sering deploy terus-menerus (continuous deploy).

• Organisasi yang menerapkan trunk-based development / continuous delivery tanpa release branch.

• Startup yang ingin very fast iterate (lebih cocok GitHub Flow atau trunk-based).

---

4. Alur kerja GitFlow — step-by-step

4.1. Inisialisasi (sekali)

Biasanya repo sudah punya main. Buat develop:

git checkout -b develop main
git push -u origin develop

4.2. Membuat feature

1. Ambil update:

   git checkout develop
   git pull origin develop

2. Buat branch feature:

   git checkout -b feature/<nama-fitur>

3. Kerja, commit secara atomic/deskriptif:

   git add .
   git commit -m "feat(auth): tambah endpoint login"

4. Push dan buat Pull Request menuju develop:

   git push -u origin feature/<nama-fitur>

Setelah review & passing CI, merge PR ke develop. Biasanya menggunakan merge commit (bukan rebase) agar histori fitur jelas. Namun tim boleh memilih squash-merge jika ingin histori linear.

4.3. Menyiapkan release

Ketika develop sudah siap untuk rilis:

1. Buat release branch:

   git checkout -b release/<versi> develop
   git push -u origin release/<versi>

2. Lakukan tugas rilis: bump version, update changelog, fix bug minor, run tests.

3. Commit perubahan, push.

4. Setelah oke, merge ke main dan tag:

   git checkout main
   git pull origin main
   git merge --no-ff release/<versi>   # mempertahankan history release
   git tag -a vX.Y.Z -m "Release vX.Y.Z"
   git push origin main
   git push origin vX.Y.Z

5. Merge kembali ke develop supaya perbaikan rilis masuk ke cabang development:

   git checkout develop
   git merge --no-ff release/<versi>
   git push origin develop

6. Delete branch release bila perlu:

   git branch -d release/<versi>
   git push origin --delete release/<versi>

4.4. Hotfix produksi

Jika bug muncul di produksi:

1. Buat hotfix dari main:

   git checkout -b hotfix/<versi-patch> main

2. Perbaiki, commit, push.

3. Merge ke main, tag, push:

   git checkout main
   git merge --no-ff hotfix/<versi-patch>
   git tag -a vX.Y.Z-patch -m "Hotfix vX.Y.Z"
   git push origin main
   git push origin vX.Y.Z-patch

4. Merge ke develop juga:

   git checkout develop
   git merge --no-ff hotfix/<versi-patch>
   git push origin develop

5. Hapus branch hotfix.

---

5. Contoh praktis (skenario nyata)

Misalkan versi sekarang v1.4.0, dan kita mengerjakan fitur auth lalu rilis v1.5.0.

5.1. Setup

# pastikan main up-to-date
git checkout main
git pull origin main

# buat develop kalau belum ada
git checkout -b develop
git push -u origin develop

5.2. Feature

git checkout develop
git checkout -b feature/auth-login
# coding...
git add .
git commit -m "feat(auth): implement login endpoint"
git push -u origin feature/auth-login
# open PR -> base: develop
# after review: merge PR (merge commit)

5.3. Release

git checkout develop
git pull origin develop
git checkout -b release/1.5.0
# bump version to 1.5.0 in package.json / pom.xml
git commit -am "chore(release): bump version to 1.5.0"
git push -u origin release/1.5.0
# run tests, fix minor issues
# then merge release -> main
git checkout main
git merge --no-ff release/1.5.0
git tag -a v1.5.0 -m "Release v1.5.0"
git push origin main
git push origin v1.5.0

# merge back to develop
git checkout develop
git merge --no-ff release/1.5.0
git push origin develop

---

6. Pilihan merge: --no-ff vs --ff-only vs rebase

• --no-ff (no fast-forward): membuat commit merge eksplisit, baik untuk release / hotfix agar histori mencerminkan event rilis.

• --ff / fast-forward: histori lebih linear, tetapi kehilangan boundary fitur/release. Jika branch tujuan belum punya commit baru sejak branch lain dibuat, Git cukup menggeser pointer ke depan. Tidak ada merge commit.

Contoh:

main: A---B
             \
release:      C---D

Jika merge normal:

main: A---B---C---D   ← pointer main digeser

Histori jadi seolah-olah commit C dan D ditulis langsung di main → informasi bahwa itu pekerjaan “release” hilang(branch seperti tidak pernah ada).

• Rebase: merapikan commit sebelum merge; bagus untuk fitur privat sebelum dibagikan. Jangan rebase branch yang sudah dipush dan dipakai orang lain.

Rekomendasi GitFlow:

• Merge PR fitur ke develop menggunakan merge commit (atau squash sesuai kebijakan tim).

• Merge release dan hotfix ke main dengan --no-ff untuk menandai rilis.

---

7. Versi dan Tagging

Biasanya dipasangkan dengan Semantic Versioning (SemVer): MAJOR.MINOR.PATCH.

• MAJOR: perubahan breaking.

• MINOR: fungsi baru kompatibel.

• PATCH: bugfix.

Praktik: setiap merge release ke main → buat annotated tag (git tag -a vX.Y.Z -m "...") → push tag.

---

8. Integrasi CI/CD

GitFlow cocok dipasangkan dengan pipeline:

• CI berjalan di setiap PR (lint, tests, build).

• Pipeline untuk develop dapat menjalankan staging deploy otomatis.

• Pipeline untuk main berjalan setelah tag dibuat → job: build artifact, publish, deploy production.

Contoh aturan:

• PR ke develop → jalankan unit tests & integration tests.

• Merge ke release/* → jalankan full test suite, build artifact, dan snapshot deploy ke staging.

• Merge ke main + tag → rilis otomatis ke production.

---

9. Best practices & aturan tim

1. Naming convention Gunakan pola: feature/<name>, bugfix/<id>-short, hotfix/<id>, release/<x.y.z>. Konsisten.

2. Atomic commits & pesan Gunakan Conventional Commits: feat:, fix:, chore:, docs: untuk memudahkan changelog otomatis.

3. PR checklist

   • Deskripsi singkat & alasan perubahan

   • Link issue / ticket

   • Test unit & integrasi lulus

   • Reviewer minimal 1–2 orang

   • Tidak ada secrets di commit

4. Jangan rebase branch publik Jika sudah dipush dan direview orang lain, hindari mengubah histori.

5. Merge strategy Putuskan apakah fitur di-merge dengan merge commit atau squash. Dokumentasikan.

6. Release notes & changelog Otomatiskan changelog dari commit atau PR (mis. conventional-changelog, release-drafter).

7. Protect branch Buat protected branches di remote (main/develop): require PR review, passing CI, no force pushes.

---

10. Konflik & resolusi

• Konflik akan muncul saat merge feature ke develop atau saat merge release ke main/develop.

• Selalu update lokal branch dari target sebelum merge:

  git checkout feature/foo
  git fetch origin
  git rebase origin/develop    # jika tim setuju rebase local
  # atau
  git merge origin/develop     # jika tim pakai merge

• Resolve conflict, run tests, commit hasil resolve, push.

Catatan: pilih strategi (rebase vs merge) secara konsisten di tim.

---

11. Kelebihan & Kekurangan GitFlow

Kelebihan

• Struktur jelas antara development & production.

• Mudah koordinasi tim besar.

• Rilis terencana dengan release branch.

• Hotfix cepat karena branch dari main.

Kekurangan

• Cukup verbose—banyak branch dan proses, overhead untuk tim kecil.

• Tidak ideal jika ingin deploy frequently (CD).

• Bisa menimbulkan merge friction bila branch lama dibiarkan terpisah lama.

---

12. Alternatif populer

• GitHub Flow: main + short-lived feature branches; cocok continuous deploy.

• Trunk-based Development: semua developer commit ke trunk (main) sering; cocok CI/CD & feature flags.

• GitLab Flow: campuran model, bisa menyesuaikan environment (staging/production).

Pilih workflow sesuai kebutuhan tim: stabilitas (GitFlow) vs kecepatan deploy (Trunk/GitHub Flow).

---

13. Contoh praktik lanjut: script helper dan tips

GitFlow helper (opsional)

Ada tool git-flow yang memfasilitasi perintah:

# install git-flow (tergantung OS)
git flow init            # inisialisasi (jawab prompt: main/develop names)
git flow feature start my-feature
git flow feature finish my-feature

git flow release start 1.5.0
git flow release finish 1.5.0

git flow hotfix start fix-urgent
git flow hotfix finish fix-urgent

Tool ini otomasi steps merge/tag, tapi beberapa tim memilih manual agar kontrol lebih jelas.

Tips performa kerja

• Buat fitur kecil (small, focused).

• Merge sering agar konflik kecil.

• Gunakan feature toggle untuk fitur besar agar bisa merge lebih awal tanpa mengaktifkan di prod.

• Automasi release notes & changelog.

---

14. Template PR untuk GitFlow

Title: feat(auth): implement login endpoint (ISSUE-123)

Description:
- Apa yang diubah: menambahkan endpoint POST /login, validasi, token issuance
- Alasan: diperlukan untuk fitur autentikasi di mobile app
- Testing: unit tests untuk auth service, integrasi lokal dengan DB container
- Checklist:
  - [x] Unit tests added
  - [x] Integration tests pass locally
  - [x] Code review by @reviewer

---

15. Checklist siap rilis (contoh)

• Semua fitur yang direncanakan ada di develop

• Semua PR ke develop sudah di-merge & CI passing

• Buat release/<versi>

• Bump version & update changelog

• Full test suite pass pada release branch

• Merge release -> main, tag, push tag

• Merge release -> develop

• Deploy ke production (otomatis / manual sesuai policy)

---

16. FAQ singkat

Q: Harus pakai develop? A: Tidak wajib, tapi GitFlow mengasumsikan develop sebagai tempat integrasi. Jika tim lebih suka main-only flows, pilih GitHub Flow atau Trunk.

Q: Apakah membuat banyak branch bikin repo berat? A: Branch di Git itu pointers, bukan salinan data — tidak membuat repo “berat” signifikan. Risiko adalah kompleksitas manajemen, bukan ukuran repo.

Q: Merge atau rebase untuk feature? A: Untuk histori tim, prefer merge (retain feature boundary). Untuk membersihkan commit pribadi, rebase lokal sebelum push.

---

17. Ringkasan & rekomendasi akhir

GitFlow adalah pola workflow yang solid untuk tim yang butuh pemisahan jelas antara development dan produksi, terutama ketika rilis terjadwal dan ada kebutuhan hotfix. Namun, jika timmu mengutamakan kecepatan deploy (continuous deployment), pertimbangkan GitHub Flow atau trunk-based.

Rekomendasi implementasi singkat:

1. Inisialisasi main + develop.

2. Gunakan feature/* untuk pengembangan, PR ke develop.

3. Siapkan release/* untuk rilis; merge ke main + tag; merge kembali ke develop.

4. Tangani urgent bug via hotfix/* dari main.

5. Protect branches, paksa PR review & CI passing.

---

18. Bonus: Quick reference — perintah penting

# buat develop
git checkout -b develop main
git push -u origin develop

# feature
git checkout -b feature/foo develop
git push -u origin feature/foo

# finish feature (manual)
git checkout develop
git merge --no-ff feature/foo
git push origin develop

# release
git checkout -b release/1.5.0 develop
# bump version, changelog, test
git commit -am "chore(release): bump 1.5.0"
git checkout main
git merge --no-ff release/1.5.0
git tag -a v1.5.0 -m "v1.5.0"
git push origin main
git push origin v1.5.0
git checkout develop
git merge --no-ff release/1.5.0
git push origin develop

# hotfix
git checkout -b hotfix/1.5.1 main
# fix, commit
git checkout main
git merge --no-ff hotfix/1.5.1
git tag -a v1.5.1 -m "hotfix v1.5.1"
git push origin main && git push origin v1.5.1
git checkout develop
git merge --no-ff hotfix/1.5.1
git push origin develop

---

Kalau kamu mau, saya bisa:

• Mengubah artikel ini jadi bahasa Inggris untuk Medium global.

• Memformat ulang jadi series (bagian 1: konsep, bagian 2: praktik & perintah, bagian 3: CI/CD).

• Menambahkan contoh file konfigurasi CI (GitHub Actions / GitLab CI) yang spesifik untuk GitFlow.

18. Saya Prefer Git Workflow yang Mana?

Saya pribadi lebih suka hal yang simple seperti Artivisi Flow yang digunakan oleh Perusahaan Artivisi. https://software.endy.muhardin.com/aplikasi/workflow-git-manajemen/