> For the complete documentation index, see [llms.txt](https://lab-sammi.gitbook.io/me/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://lab-sammi.gitbook.io/me/mengenal-gitflow.md).

# 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`:

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

#### 4.2. Membuat feature

1. Ambil update:

   ```bash
   git checkout develop
   git pull origin develop
   ```
2. Buat branch feature:

   ```bash
   git checkout -b feature/<nama-fitur>
   ```
3. Kerja, commit secara atomic/deskriptif:

   ```bash
   git add .
   git commit -m "feat(auth): tambah endpoint login"
   ```
4. Push dan buat Pull Request menuju `develop`:

   ```bash
   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:

   ```bash
   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:

   ```bash
   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:

   ```bash
   git checkout develop
   git merge --no-ff release/<versi>
   git push origin develop
   ```
6. Delete branch release bila perlu:

   ```bash
   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`:

   ```bash
   git checkout -b hotfix/<versi-patch> main
   ```
2. Perbaiki, commit, push.
3. Merge ke `main`, tag, push:

   ```bash
   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:

   ```bash
   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

```bash
# 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:

  ```bash
  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:

```bash
# 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)

* [ ] &#x20;Semua fitur yang direncanakan ada di `develop`
* [ ] &#x20;Semua PR ke `develop` sudah di-merge & CI passing
* [ ] &#x20;Buat `release/<versi>`
* [ ] &#x20;Bump version & update changelog
* [ ] &#x20;Full test suite pass pada `release` branch
* [ ] &#x20;Merge `release` -> `main`, tag, push tag
* [ ] &#x20;Merge `release` -> `develop`
* [ ] &#x20;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

```bash
# 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/**](https://software.endy.muhardin.com/aplikasi/workflow-git-manajemen/)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://lab-sammi.gitbook.io/me/mengenal-gitflow.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.