Git Workflow untuk Solo Developer: Branch Strategy, Commit Message, dan Automation

“Solo developer sering malas pakai Git dengan benar — ‘kan cuma saya sendiri’. Tapi setelah seminggu absen dari project, commit message ‘update’ dan ‘fix’ saja sudah tidak cukup. Semua berubah jadi mimpi buruk waktu ada bug yang harus di-rollback. Artikel ini menyelamatkan kamu dari kekacauan Git solo.”

Pernah merasakan ini: kamu membuka proyek yang terakhir kamu kerjakan dua minggu lalu, dan sama sekali tidak ingat apa yang barusan kamu lakukan? Atau ada kode baru yang error dan kamu nggak tahu perubahan mana yang nyebabin?

Kalau kamu solo developer dan tidak punya branch strategy sama sekali — atau yang kamu lakukan cuma git add . && git commit -m "update" setiap malam — artikel ini untuk kamu.

Inilah Git workflow yang saya gunakan sebagai solo developer. Sederhana, konsisten, dan akan menyelamatkan kamu dari sakit kepala di masa depan.

Kenapa Solo Developer Tetap Butuh Git yang Rapi?

Alasan klasik yang sering didengar: “Saya cuma sendiri kok, ngapain pakai branching, ngapain pakai commit message rapi?”

Ada empat masalah yang hanya muncul kalau kamu baru ngerasain sendiri:

• Rollback horror — Commit “fix bug” ternyata mencakup 12 perubahan di 8 file berbeda, dan kamu tidak tahu mana yang relevan dengan bug itu.
• Konflik dengan diri sendiri — Merge conflict antara branch yang kamu buat dua hari lalu dan main branch adalah hal yang nyata dan sangat menyebalkan.
• Debugging buta — Saat tiba-tiba fitur yang sudah jalan seminggu berhenti bekerja, kamu harus membaca seluruh kode karena tidak ada jejak commit yang jelas.
• Portofolio yang tidak profesional — Commit history yang berantakan di GitHub sama seperti resume yang tidak rapi. Perekrut teknologi memang melihat commit history.

Branch Strategy untuk Solo Developer yang Realistis

Berbeda dengan tim besar yang butuh Git Flow dengan develop, staging, release, dan hotfix branches — solo developer cukup dengan model yang lebih ramping: Trunk-Based Development versi sederhana.

Cukup Dua Branch Utama

• main — Kode yang sudah siap produksi. Setiap commit di sini adalah kode yang aman dan sudah teruji.
• dev — Tempat fitur yang sedang dikembangkan. Kode di sini boleh mentah, boleh ada yang error — ini playground kamu.

Aturan mainnya sesederhana ini: jangan pernah commit langsung ke main. Semua pekerjaan dilakukan di dev, dan hanya commit yang sudah stabil dan selesai yang di-merge ke main.

Branch untuk Fitur Baru

Kalau kamu mengerjakan fitur yang kompleks — misalnya “fitur reset password” atau “integrasi payment gateway” — jangan langsung di dev. Buat branch fitur terpisah menggunakan pola penamaan yang konsisten:

git checkout -b feat/reset-password
git checkout -b feat/payment-gateway
git checkout -b fix/login-timeout
git checkout -b refactor/database-queries

Pola prefix yang saya gunakan:

• feat/ — Fitur baru
• fix/ — Perbaikan bug
• refactor/ — Perubahan kode tanpa mengubah fungsionalitas
• docs/ — Perubahan dokumentasi
• chore/ — Tugas rutin seperti update dependency

Begitu fitur selesai, merge ke dev dulu, uji sebentar, baru merge ke main:

git checkout dev
git merge feat/reset-password
# uji fitur sebentar...
git checkout main
git merge dev
git tag -a v1.2.0 -m "Tambahkan fitur reset password"
git branch -d feat/reset-password

Commit Message yang Membantu Masa Depan Kamu

Commit message bukan untuk orang lain — untuk kamu enam bulan yang akan datang yang membaca commit history sambil bingung “apa yang saya lakukan waktu itu?”

Gunakan format Conventional Commits — sederhana dan sangat informatif:

<type>: <deskripsi singkat>

[opsional: penjelasan lebih detail di body]

Contoh:

feat: tambah fitur reset password via email

- Kirim OTP ke email pengguna
- Validasi OTP sebelum mengizinkan perubahan password
- Kirim notifikasi setelah password berhasil diubah

Type yang paling sering digunakan:

• feat — Fitur baru
• fix — Perbaikan bug
• refactor — Perubahan kode tanpa perubahan fungsi
• docs — Perubahan dokumentasi
• chore — Tugas rutin (update dependency, config)
• test — Menambah atau memperbaiki test
• style — Perubahan format, whitespace, titik koma

Bedanya dengan commit “update” yang biasa kamu buat? Coba lihat sendiri:

❌ update
❌ fix
❌ tambah fitur
❌ ganti dikit
❌.
❌.

✅ feat: tambah halaman dashboard dengan grafik penjualan
✅ fix: perbaiki bug validasi email di form registrasi
✅ chore: upgrade Laravel 10 ke 11
✅ refactor: pisahkan logika autentikasi ke service class

Enam bulan kemudian, git log --oneline kamu jadi jauh lebih bermakna karena kamu bisa langsung tahu mana commit yang relevan dengan perubahan yang kamu cari.

Automation: Biarkan Mesin yang Mengingatkan

Konsistensi dengan Git bukan hanya soal kemauan — soal kebiasaan. Dan kebiasaan terbantu dengan automasi.

Git Hooks: Commit Message Linter

Pasang commitlint sebagai Git hook untuk memastikan commit message kamu selalu mengikuti format Conventional Commits:

# Install commitlint
npm install -g @commitlint/cli @commitlint/config-conventional

# Setup hook
echo "module.exports = {extends: ['@commitlint/config-conventional']}" > commitlint.config.js
npx husky install
npx husky add .husky/commit-msg 'npx --no -- commitlint --edit $1'

Kalau kamu pakai Python dan belum pakai Node.js, alternatif ringan:

#!/bin/sh
# .git/hooks/commit-msg
# Simple commit message linter tanpa dependency

commit_msg=$(cat "$1")

if echo "$commit_msg" | grep -qE "^(feat|fix|refactor|docs|chore|test|style)\(?.*?\)?:\s"; then
    exit 0
else
    echo "ERROR: Commit message harus mengikuti format: type: deskripsi"
    echo "Contoh: feat: tambah fitur reset password"
    exit 1
fi

Semantic Versioning dengan Tag

Setiap kali kamu merge ke main, beri tag versi. Tidak perlu rumit — cukup ikuti SemVer (MAJOR.MINOR.PATCH):

git tag -a v1.0.0 -m "Rilis pertama"
git tag -a v1.1.0 -m "Tambah fitur reset password"
git tag -a v1.1.1 -m "Perbaiki bug login"

Aturan SemVer sederhana untuk solo developer:

• MAJOR — Ada perubahan yang tidak kompatibel dengan versi sebelumnya (API berubah, database migration, dll)
• MINOR — Fitur baru yang tetap kompatibel
• PATCH — Perbaikan bug atau perubahan kecil

Bonus: Auto-Generate Changelog

Dengan Conventional Commits, kamu bisa generate CHANGELOG.md otomatis menggunakan tool seperti standard-version atau git-cliff:

# Install git-cliff
cargo install git-cliff
# atau pakai binary: https://github.com/orhun/git-cliff/releases

# Generate changelog berdasarkan commit history
git cliff -o CHANGELOG.md

# Update versi dan tag otomatis
git cliff --bump

Hasilnya: changelog yang rapi, ready untuk dipajang di GitHub Releases atau di README proyek kamu.

Workflow Harian yang Saya Gunakan

Ini alur kerja sehari-hari yang sangat sederhana. Kamu bisa tiru persis:

1. Pagi: git checkout dev && git pull — pastikan dev dalam kondisi terbaru
2. Mulai fitur baru: git checkout -b feat/nama-fitur
3. Bekerja: coding sambil commit kecil-kecil — setiap selesai satu bagian, commit (jangan menumpuk 10 perubahan dalam satu commit besar)
4. Selesai fitur: git checkout dev && git merge feat/nama-fitur — uji di dev dulu
5. Release: git checkout main && git merge dev && git tag -a v1.x.x
6. Hapus branch fitur: git branch -d feat/nama-fitur

Selesai. Tidak perlu 20 branch, tidak perlu birokrasi yang bikin kamu malas.

Checklist Setup Awal

Mulai hari ini, lakukan 3 hal ini:

• ✅ Buat branch dev di proyek kamu sekarang
• ✅ Setup commitlint (atau shell script hook sederhana) — 5 menit
• ✅ Buat .gitignore yang rapi dan .gitmessage template commit

Commit pertama di branch dev kamu hari ini. Dengan format chore: setup git workflow. Dua bulan dari sekarang, kamu akan berterima kasih pada dirimu sendiri.

---

Artikel ini adalah bagian dari seri “Toolchain Developer Solo” — tips dan workflow praktis yang langsung bisa dipakai tanpa overhead tim.