Git Workflow untuk Solo Developer

Kalau kamu baca tutorial Git workflow di internet, hampir semuanya berasumsi kamu punya rekan tim. GitFlow, trunk-based development, etika code review, semantic commit yang dipaksa bot — semuanya dirancang seputar tim yang menegosiasikan cara berbagi codebase.

Tapi banyak dari kita menghabiskan sebagian besar waktu di repo yang timnya cuma satu orang. Side project, kerjaan freelance, project klien kecil, eksperimen. Workflow ala tim dua belas orang nggak cocok, tapi commit langsung ke main dengan pesan "wip" dan "fix again" juga sama-sama nggak benar. Kamu tetap butuh workflow — cuma yang dirancang untuk constraint sebenarnya, yaitu diri kamu sendiri tiga minggu ke depan yang lagi mencoba mengingat-ingat apa yang sudah kamu kerjakan.

Ini workflow yang saya pakai di seluruh repo solo saya. Sengaja dibikin "membosankan". Tujuannya meninggalkan jejak yang bersih dan bikin rollback jadi murah, bukan mengoptimalkan koordinasi tim yang memang nggak ada.

Branching: pendek, satu tujuan

Saya kerja di main. Itu branch production. Apa pun yang ter-deploy berasal dari sana.

Untuk perubahan yang lebih besar dari satu baris typo, saya bikin branch:

git checkout -b feat/blog-mdx

Konvensi penamaan cuma tiga prefix:

• feat/ untuk fitur baru
• fix/ untuk bug fix
• chore/ untuk refactor, dependency, tooling

Sudah, itu saja. Nggak ada nomor tiket, nggak ada JIRA ID, nggak ada inisial tim. Tugas nama branch cuma satu: mengingatkan saya sedang ngerjain apa setelah saya context-switch balik dari makan siang.

Branch tetap pendek. Kalau ada branch yang hidup lebih dari beberapa hari, biasanya artinya saya gigit lebih banyak dari yang bisa dikunyah dan harusnya ngeship versi yang lebih kecil dulu. Branch yang hidup lama akan drift, dan merge-nya berubah jadi pekerjaan arkeolog.

Commit: satu perubahan logis per commit

Di sinilah workflow solo menggoda kamu untuk asal-asalan. Toh nggak ada yang ngereview diff-nya, ngapain repot-repot menata commit?

Karena orang yang bakal review diff itu adalah kamu sendiri, tiga minggu lagi, ketika production rusak dan kamu perlu bisect atau revert. Riwayat commit yang bersih adalah alat debugging. Yang berantakan adalah hukuman.

Aturan yang saya pegang: satu commit = satu perubahan logis, dengan pesan yang bisa melengkapi kalimat "commit ini akan ___".

Bagus:

feat(blog): add MDX rendering with frontmatter and reading time
fix(api): handle empty filter array in /projects query
chore: bump next to 14.2 and patch breaking imports

Buruk:

wip
fix
update stuff
asdf

Format-nya loose Conventional Commits. Saya pakai karena bikin git log --oneline benar-benar bisa di-scan, bukan karena ada bot yang memaksa.

Kalau saya lagi ngoprek dan akhirnya punya tiga perubahan logis yang campur aduk, saya pakai git add -p untuk staging mereka terpisah dan commit masing-masing dengan pesannya sendiri. Tambah dua menit. Hemat sejam nanti.

Pull request: iya, bahkan di repo solo

Saya tetap buka PR ke main walaupun yang nge-merge cuma saya sendiri. Tiga alasan:

1. CI jalan di PR. Vercel preview deploy, lint, test, type-check. Kalau ada yang rusak, saya tahu sebelum main rusak.
2. Diff view adalah forcing function. Ngeliat perubahan kamu sendiri di tampilan PR menangkap hal-hal yang git diff di terminal lewatkan — console.log yang nggak sengaja ketinggalan, code yang ke-comment, file yang nggak niat kamu sentuh.
3. Deskripsi PR adalah changelog built-in. Pas saya balik enam bulan kemudian, PR itu jadi dokumentasi kenapa perubahan terjadi, bukan cuma apa yang berubah.

Saya nulis PR seolah-olah lagi me-review buat orang asing. Ringkasan di atas, apa yang berubah, apa yang sudah saya verifikasi. Habis itu saya merge sendiri, biasanya pakai squash biar history main tetap satu-commit-per-fitur.

Kapan boleh skip branch

Workflow solo harus ergonomis atau kamu bakal melewatinya. Saya commit langsung ke main ketika:

• Memperbaiki typo di komentar atau dokumentasi
• Naikin satu dependency yang nggak mengubah behavior
• Update config value (env var, model name) yang memang perlu di-test langsung di production

Aturannya: kalau perubahannya bisa di-revert dengan satu baris dan nggak layak buat deskripsi PR, langsung ke main. Kalau lebih dari itu, bikin branch.

Tag dan release: changelog termurah

Untuk project yang ship ke production, saya tag setiap release:

git tag -a v0.4.0 -m "Add /blogs MDX rendering, refactor projects filter"
git push --tags

Ini cuma butuh sekitar sepuluh detik per release dan kamu dapat:

• Titik rollback yang bersih — git checkout v0.3.0 kalau v0.4 ternyata jadi bencana
• History yang bisa di-scroll, kapan apa di-ship
• Sesuatu untuk ditunjukkan ke klien pas mereka tanya "ada apa aja sejak bulan lalu"

Saya nggak ngikutin SemVer ketat untuk kerjaan solo. Kalau saya ngeship sesuatu yang user-visible, minor version naik. Kalau saya harus break URL atau format yang tersimpan, major naik. Patch buat bug fix yang sudah ter-ship. Sebatas itu sudah cukup struktur.

Rebase: iya, tapi hati-hati

Saya rebase branch saya sendiri sebelum merge kalau commit history-nya udah berantakan:

git rebase -i main

Squash typo-nya, reword pesan yang jelek, drop commit eksperimental yang sudah saya batalkan. Branch-nya mendarat dengan bersih.

Saya nggak rebase apa pun yang sudah di-push dan dibagikan, bahkan di repo solo — begitu CI deploy atau Vercel preview sudah build dari satu commit SHA, SHA itu harus terus berarti hal yang sama. Menulis ulang history setelah titik itu bakal merusak link ke deployment, screenshot di PR, dan hasil pencarian di log saya sendiri.

Yang saya nggak lakuin

Beberapa hal yang ditekankan di tutorial workflow tim, yang saya skip di repo solo:

• Nggak pakai develop branch. Itu cuma merge tambahan tanpa benefit review ketika tim cuma satu orang. main adalah develop.
• Nggak mewajibkan issue linking. Saya tracking kerjaan di aplikasi todo, bukan GitHub issues, untuk project solo. Issues itu buat hal-hal yang saya pengen orang asing bisa file.
• Nggak pakai release branch. Tag bisa kerja yang sama, gratis.
• Nggak menerapkan commit signing. Berguna untuk trust di open source, overkill di project sampingan privat.

Pola yang konsisten

Semua bagian di atas mengerucut ke satu prinsip: bikin setiap perubahan bisa di-review, di-revert, dan di-label, walaupun nggak ada orang lain yang mereview. Sebatas itu workflow-nya.

Diri kamu di masa depan adalah reviewer paling penting yang akan pernah kamu punya. Perlakukan pengalaman mereka dengan baik.