Pernah membuat mess di repository karena workflow yang tidak jelas? Merge conflict di mana-mana, branch yang numpuk tanpa ada yang tau masih aktif atau tidak, commit message “fix” tanpa penjelasan lebih lanjut — dan itu semua kamu yang membuat sendiri.
Kalau ya, artikel ini untuk kamu.
Git workflow yang bagus bukan soal mengikuti textbook dengan sempurna. Ini soal menemukan sistem yang cukup simple untuk diikuti konsisten, tapi cukup terstruktur untuk tidak membuat pusing di kemudian hari.
Mengapa Workflow Penting (Bahkan untuk Solo Developer)
Banyak developer solo berpikir: “Ngapain ribet workflow, toh ini project sendiri.”
Tapi coba bayangkan kamu buka project yang sudah 3 bulan tidak disentuh. Branch mana yang terakhir dipakai? Kenapa ada 5 branch dengan nama “feature-payment” dengan angka berbeda? Commit terakhir bilang “update” — update apa? Dan mengapa commit itu ada di main?
Git workflow bukan untuk tim besar saja. Ini untuk kamu di masa depan yang harus baca pekerjaan kamu di masa lalu.
Workflow Rekomendasi: Simplified Git Flow
Untuk tim 1-5 orang (atau solo), Git Flow penuh terlalu berat. GitHub Flow terlalu minimalis untuk project yang punya release cycle. Yang paling pas: Simplified Git Flow.
Branch Utama
main → kode production-ready, selalu bisa di-deploy
develop → integrasi ongoing work, staging environment
Optional (untuk yang punya ritme release):
release/v1.2 → persiapan release, hanya bugfix
hotfix/xxx → perbaikan critical langsung dari main
Naming Convention Branch
Pakai prefix yang jelas:
feature/nama-fitur
fix/deskripsi-bug
chore/task-maintenance
docs/update-readme
refactor/nama-komponen
Contoh konkret:
feature/user-authentication
fix/cart-total-calculation-error
chore/update-dependencies
docs/api-endpoint-documentation
Commit Message yang Bermakna
Ini yang paling sering disepelekan. Commit message bukan formalitas — ini dokumentasi real-time yang bisa menyelamatkan jam debugging di masa depan.
Format yang Disarankan: Conventional Commits
<type>(<scope>): <deskripsi singkat>
[optional body]
[optional footer]
Tipe yang umum:
feat— fitur barufix— bug fixdocs— perubahan dokumentasistyle— formatting, bukan perubahan logicrefactor— restrukturisasi tanpa mengubah behaviortest— menambah atau memperbaiki testchore— maintenance, update dependency
Contoh commit yang buruk vs baik:
# Buruk:
git commit -m "fix"
git commit -m "update login"
git commit -m "wip"
Baik:
git commit -m "fix(auth): handle expired token pada middleware JWT"
git commit -m "feat(payment): tambah integrasi Midtrans payment gateway"
git commit -m "refactor(cart): pisah kalkulasi diskon ke fungsi terpisah"
Pull Request: Bahkan untuk Tim Kecil
“Ngapain PR kalau cuma kita-kita?” — Ini pertanyaan yang valid, tapi ada alasan kuat untuk tetap pakai PR:
- Review diri sendiri — buka PR, baca diff sendiri sebelum merge. Surprising betapa banyak hal kecil yang ketahuan di sini.
- Trail yang jelas — setiap fitur punya PR, setiap PR bisa dilacak ke issue atau task.
- CI/CD trigger — pipeline otomatis (test, lint, build) bisa di-trigger dari PR event.
- Onboarding lebih mudah — kalau nanti ada anggota baru, mereka bisa baca history PR untuk memahami konteks keputusan.
Template PR Sederhana
## Apa yang berubah?
[Deskripsi singkat]
Kenapa perlu perubahan ini?
[Konteks dan motivasi]
Cara test?
- [ ] Step 1
- [ ] Step 2
Screenshot (kalau ada perubahan UI)
Strategi Merge: Pilih dan Konsisten
Ada tiga cara merge di Git, masing-masing punya trade-off:
1. Merge Commit (default)
git merge feature/nama-fitur- History yang jelas kapan branch di-merge
- Graph history bisa jadi ramai
- Cocok untuk: feature branch ke develop
2. Squash and Merge
git merge --squash feature/nama-fitur- Semua commit di branch jadi satu commit bersih di target
- History lebih bersih, tapi kehilangan granular history
- Cocok untuk: PR kecil dengan banyak “wip” commit
3. Rebase and Merge
git rebase main && git merge- Linear history, tidak ada merge commit
- Bisa membuat masalah kalau tidak paham cara kerjanya
- Cocok untuk: developer yang sudah paham Git dengan baik
Rekomendasi untuk tim kecil: Squash and Merge untuk feature → develop, Merge Commit untuk develop → main/release.
Tagging dan Release
Pakai semantic versioning: v
# Tag setelah merge ke main
git tag -a v1.2.0 -m "Release v1.2.0: tambah fitur payment"
git push origin v1.2.0
- Major (1.x.x → 2.x.x): breaking change
- Minor (1.2.x → 1.3.x): fitur baru backward-compatible
- Patch (1.2.3 → 1.2.4): bug fix
.gitignore yang Wajib Ada
Jangan skip ini. Beberapa hal yang tidak boleh masuk repository:
# Environment variables
.env
.env.local
.env.production
Dependencies
node_modules/
vendor/
Build output
dist/
build/
.next/
IDE files
.vscode/
.idea/
*.swp
OS files
.DS_Store
Thumbs.db
Logs
*.log
npm-debug.log*
Setup Minimal untuk Workflow Ini
Untuk tim kecil, tools ini cukup:
- GitHub/GitLab — hosting repository, PR management, issue tracker
- GitHub Actions / GitLab CI — CI/CD pipeline (free tier biasanya cukup)
- Commitlint — enforce conventional commit format
- Husky — pre-commit hooks (jalankan lint/test sebelum commit)
// package.json (kalau pakai Node.js)
{
"husky": {
"hooks": {
"pre-commit": "npm run lint",
"commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
}
}
}
Checklist Sebelum Merge
Buat kebiasaan check ini sebelum merge apapun ke main:
- [ ] Test sudah jalan dan pass
- [ ] Tidak ada
console.logdebug yang tertinggal - [ ] Environment variables baru sudah didokumentasi
- [ ] Tidak ada secret atau credentials di kode
- [ ] Commit message mengikuti convention
- [ ] PR description sudah terisi
Kesimpulan
Git workflow yang baik bukan tentang mengikuti semua rules textbook. Ini tentang memilih sistem yang kamu dan tim kamu akan ikuti secara konsisten. Mulai simpel, tambah kompleksitas hanya ketika kamu punya masalah nyata yang membutuhkan solusi lebih terstruktur.
Yang terpenting: konsistensi mengalahkan kesempurnaan.
Mau review Git workflow project kamu atau butuh setup CI/CD yang proper untuk tim kecil? Yuk ngobrol — hubungi mafadev dan kita rancang bareng sistem yang sesuai.
Leave a Reply