Konvensi, Otomasi
& Workflow Tim

Release, kebersihan repo, dan automasi pesan

Empat alat kebersihan yang membuat repo bisa dirilis dengan rapi dan dijaga tetap bersih tanpa disiplin manual.

Sejauh ini fokus kita pada bagaimana commit mengalir. Section ini melengkapi gambar dengan empat hal di sekelilingnya, menandai titik rilis (tag), menjaga file yang tak layak masuk (.gitignore), menjalankan pengecekan otomatis di momen tepat (hooks), dan menyepakati format pesan (Conventional Commits). Keempatnya saling menguatkan, tag dan pesan terstruktur memungkinkan changelog otomatis, hook memaksa pesan itu valid sebelum commit terbentuk.

Tag: menandai versi rilis

Tag adalah penanda permanen pada sebuah commit, biasanya untuk versi rilis. Ada dua jenis. Lightweight tag hanya pointer ke commit, seperti branch yang tidak bergerak. Annotated tag adalah objek penuh dengan nama tagger, tanggal, pesan, dan bisa ditandatangani GPG. Untuk rilis publik selalu pakai annotated.

TerminalSalin
git tag -a v1.0.0 -m "Rilis publik pertama skincare-backend"
git tag                       # daftar tag lokal
git show v1.0.0               # lihat objek tag + commit yang ditunjuk
git push origin v1.0.0        # tag tidak ikut push biasa, dorong eksplisit
git push origin --tags        # atau dorong semua tag sekaligus

Penomoran versi mengikuti Semantic Versioning, MAJOR.MINOR.PATCH. MAJOR naik saat ada perubahan yang memecah kompatibilitas, MINOR saat ada fitur baru yang tetap kompatibel, PATCH saat hanya perbaikan bug. Pemetaan ini bukan kebetulan, ia selaras persis dengan Conventional Commits di bawah.

.gitignore: menjaga repo tetap bersih

Repo backend tidak perlu menyimpan dependensi, rahasia, atau hasil build. File-file itu besar, berbeda per mesin, atau berbahaya bila bocor. .gitignore mendaftar pola yang Git abaikan.

.gitignoreSalin
# dependensi & build
node_modules/
/bin/
/tmp/
*.exe

# rahasia (JANGAN pernah commit)
.env
.env.*
!.env.example

# file OS & editor
.DS_Store
Thumbs.db
.idea/
.vscode/

Pola membaca seperti ini, / di akhir berarti hanya cocok direktori, / di awal meng-anchor relatif ke lokasi file .gitignore, dan tanpa / cocok di level mana pun. Tanda ! me-re-include file yang tadinya terabaikan, di contoh atas .env.* mengabaikan semua varian tapi .env.example tetap dilacak agar tim tahu kunci apa yang dibutuhkan. Untuk pola lintas semua proyek (mis. .DS_Store), pakai global ignore via git config --global core.excludesFile ~/.config/git/ignore.

Git hooks: automasi di momen tepat

Hook adalah skrip yang Git jalankan otomatis pada event tertentu. Tiga yang paling berguna di sisi klien, pre-commit (sebelum pesan ditulis, untuk lint/format/test cepat), commit-msg (validasi format pesan), dan pre-push (cek terakhir sebelum objek dikirim ke remote). Bila hook keluar dengan kode non-nol, operasi dibatalkan.

.git/hooks/pre-commitSalin
#!/bin/sh
# format & vet sebelum snapshot commit terbentuk
gofmt -l . | grep . && echo "Jalankan gofmt dulu" && exit 1
go vet ./... || exit 1
exit 0

Hook hidup di .git/hooks/ dan tidak ikut saat clone, jadi disiplin tim tidak terjaga sendiri. Karena itu tim memakai manajer hook yang menyimpan konfigurasi di dalam repo dan memasangnya lewat core.hooksPath. Tiga pilihan yang dominan, dengan karakter yang berbeda:

Conventional Commits: pesan yang bisa diolah mesin

Conventional Commits 1.0.0 menstandarkan baris pertama pesan menjadi type(scope): description. Tipe yang lazim, feat (fitur baru), fix (perbaikan bug), docs, refactor, test, dan chore. Karena formatnya konsisten, alat bisa membaca riwayat untuk menghasilkan changelog dan menentukan versi otomatis.

Contoh pesanSalin
feat(cart): tambah endpoint POST /v1/carts/items

Hitung subtotal pakai PriceRupiah int64 agar bebas galat pembulatan.

fix(auth): tolak token kedaluwarsa dengan 401
refactor(order): pisahkan service dari handler
feat(api)!: ubah field harga jadi PriceRupiah, hapus "price_float"

BREAKING CHANGE: respons /v1/products kini memakai price_rupiah.

Pemetaan ke SemVer langsung, fix menaikkan PATCH, feat menaikkan MINOR, dan perubahan yang memecah kompatibilitas (ditandai ! setelah type atau footer BREAKING CHANGE:) menaikkan MAJOR. Tipe lain seperti docs, style, build, ci, dan chore tidak mengubah versi kecuali memuat BREAKING CHANGE, dan daftar tipe ini distandarkan oleh konfigurasi populer @commitlint/config-conventional (berbasis konvensi Angular).

GitHub Flow, GitLab Flow, Git Flow, Trunk-Based, plus hotfix

Workflow bukan aturan baku, ia cara tim menyepakati bagaimana cabang mengalir dari ide ke produksi.

Semua perintah yang sudah kamu kuasai (branch, merge, PR, rebase) adalah huruf. Workflow adalah kalimatnya, kesepakatan kapan membuat branch, ke mana ia merge, dan kapan kode mencapai pengguna. Tidak ada yang “paling benar”, yang ada adalah yang paling cocok dengan ukuran tim dan irama deployment. Mari telusuri dari yang paling sederhana.

GitHub Flow: sesederhana mungkin

GitHub Flow hanya punya satu cabang abadi, main, yang selalu siap deploy. Setiap pekerjaan lahir sebagai branch pendek dari main, dibuka sebagai Pull Request untuk review dan CI, lalu di-merge kembali dan langsung di-deploy. Branch berumur jam atau hari, bukan minggu.

gitGraph
  commit id: "init"
  commit id: "main siap"
  branch feat/cart
  checkout feat/cart
  commit id: "add cart"
  commit id: "test cart"
  checkout main
  merge feat/cart tag: "deploy"
  branch fix/auth
  checkout fix/auth
  commit id: "fix 401"
  checkout main
  merge fix/auth tag: "deploy"

GitHub Flow. Garis utama lurus, cabang lahir pendek lalu kembali dan langsung dirilis.

GitLab Flow: menambah environment branch

Saat deploy tidak instan dan perlu tahap (staging dulu, baru produksi), GitHub Flow kurang. GitLab Flow menambah environment branch. Fitur tetap merge ke main, lalu main dipromosikan downstream lewat merge request berurutan. Menurut dokumentasi GitLab, commit hanya mengalir ke hilir setelah teruji di tiap environment.

flowchart LR
  F[feature branch] -->|MR + review| M[main]
  M -->|promote| S[staging]
  S -->|MR| P[pre-production]
  P -->|MR| PR[production]

GitLab Flow dengan environment branch. Kode hanya bergerak ke kanan, tiap panah adalah gerbang yang sudah lolos uji.

Git Flow: lengkap tapi berat

Git Flow memakai banyak cabang berumur panjang, main (rilis), develop (integrasi), plus feature/*, release/*, dan hotfix/*. Cocok untuk produk dengan rilis berversi terjadwal, tapi sering terlalu berat untuk tim kecil yang deploy harian.

gitGraph
  commit id: "main"
  branch develop
  commit id: "dev base"
  branch feature/cart
  commit id: "cart"
  checkout develop
  merge feature/cart
  branch release/1.2
  commit id: "stabilize"
  checkout main
  merge release/1.2 tag: "v1.2.0"
  branch hotfix/1.2.1
  commit id: "patch"
  checkout main
  merge hotfix/1.2.1 tag: "v1.2.1"
  checkout develop
  merge hotfix/1.2.1

Git Flow. Dua cabang abadi (main + develop) plus release dan hotfix, perhatikan hotfix di-back-merge ke develop agar perbaikan tidak hilang.

Trunk-Based dan dua alur khusus

Trunk-Based Development mendorong integrasi sangat sering ke satu trunk dengan branch berumur sangat pendek (jam, bahkan langsung). Fitur yang belum siap disembunyikan di balik feature flag, bukan ditahan di branch panjang, sehingga konflik besar nyaris tak pernah terjadi. Di luar alur utama, dua pola sering muncul. Hotfix, cabang dari tag atau main untuk patch darurat, review cepat, tag versi PATCH baru, lalu back-merge agar perbaikan ikut ke cabang pengembangan. Release branch, cabang stabilisasi paralel tempat hanya bugfix yang diterima, sementara main jalan terus untuk fitur berikutnya, menghasilkan release candidate sebelum tag final.

Dari perintah jadi kesepakatan tim

Konvensi menjaga repo bersih dan bisa dirilis otomatis; workflow menata alur cabang sesuai ukuran tim.

Kamu kini bisa menata Git untuk dipakai banyak orang. Tag annotated menandai rilis ber-SemVer, .gitignore menjaga repo dari file yang tak layak, hooks (lefthook untuk Go polyglot, husky untuk Node, pre-commit untuk katalog luas) menegakkan kualitas di gerbang commit, dan Conventional Commits membuka jalan otomasi changelog plus versi lewat commitlint, semantic-release, atau release-please. Di sisi alur, kamu bisa memilih dari GitHub Flow yang sederhana sampai Trunk-Based yang dipakai tim elite, dengan prinsip mulai sederhana. Chapter 7 menutup course: topik skala dan pemulihan, lalu rangkuman workflow rekomendasi per ukuran tim.