Belajar Git Branching Strategies - Release Management & Version Branching

#Pendahuluan

Setelah di episode 8 kita mempelajari GitLab Flow — environment branches untuk deployment hierarchy — pada episode ini kita masuk ke aspek kritis lain dari branching strategy: release management. Bagaimana cara menandai versi rilis, mengelola release candidate, dan menghasilkan changelog secara otomatis.

Release management adalah jembatan antara kode yang sudah selesai dan produk yang di-deploy ke user. Tanpa manajemen rilis yang baik, kalian tidak tahu versi mana yang sedang berjalan di production, bagaimana cara rollback, dan apa yang berubah antar versi.

#Release Branch Strategy

#Membuat Release Branch

Di GitFlow, release branch lahir dari develop:

Buat release branch dari develop

git switch develop
git checkout -b release/v1.2.0

Di GitHub Flow atau GitLab Flow, release branch bisa lahir dari main:

Buat release branch dari main

git switch main
git checkout -b release/v1.2.0

#Freeze Fitur di Release Branch

Saat release branch dibuat, freeze fitur baru. Hanya boleh bugfix di branch ini:

Bugfix di release branch

git switch release/v1.2.0
git commit -m "fix: perbaiki validasi email di registration"

Setelah stabil, merge ke main (dan develop jika pakai GitFlow).

#Semantic Versioning (SemVer)

SemVer adalah standar penamaan versi: MAJOR.MINOR.PATCH (contoh: v1.2.3).

Komponen	Kapan Increment	Contoh
MAJOR	Breaking changes — API berubah tidak kompatibel	`v1.2.3` → `v2.0.0`
MINOR	Fitur baru, backwards compatible	`v1.2.3` → `v1.3.0`
PATCH	Bug fix, backwards compatible	`v1.2.3` → `v1.2.4`

#Annotated Tag vs Lightweight Tag

Git tag adalah penanda commit tertentu. Ada dua jenis:

Annotated tag (recommended untuk release):

Buat annotated tag untuk release

git tag -a v1.2.0 -m "Release 1.2.0: tambah fitur search & perbaiki validasi"

Lightweight tag (untuk penanda sementara):

Buat lightweight tag

git tag v1.2.0

Annotated tag menyimpan metadata (penulis, pesan, tanggal) dan direkomendasikan untuk release karena lebih informatif.

#Changelog Otomatis dari Conventional Commits

Jika kalian menggunakan Conventional Commits (feat:, fix:, docs:), changelog bisa dihasilkan secara otomatis.

#Menggunakan conventional-changelog

Generate changelog dari conventional commits

npx conventional-changelog -p angular -i CHANGELOG.md -s

#Menggunakan release-please (Google)

Setup release-please

npx release-please release-pr --repo-url=github.com/user/repo

release-please membuat PR otomatis yang berisi versi baru dan changelog. Saat PR di-merge, release dibuat secara otomatis.

100%

Tip

Jika repo kalian sudah menggunakan semantic-release (seperti di project ini), changelog dan version bump sudah diotomasi. Cukup ikuti Conventional Commits dan biarkan semantic-release bekerja.

#Penutup

Pada episode 9 ini, kalian telah memahami Release Management:

Release branch dibuat dari develop atau main, fitur di-freeze, hanya bugfix.
SemVer (MAJOR.MINOR.PATCH) menentukan kapan increment masing-masing komponen.
Annotated tags (git tag -a) direkomendasikan untuk release karena menyimpan metadata.
Changelog otomatis bisa dihasilkan dari Conventional Commits menggunakan conventional-changelog atau release-please.

Di episode 10 selanjutnya kita akan mempelajari Hotfix Workflow & Emergency Patches — bagaimana menangani bug di production yang mempengaruhi user, hotfix branch pattern, dan perbedaan hotfix vs feature branch. Sampai jumpa di episode 10!