Solo Developer Nggak Butuh Gitflow

Kadang saya suka mikir, “sebenernya saya ini lagi ngoding fitur, atau lagi main administrasi file?”

Pernah ngerasain hal yang sama? Niatnya cuma pengen nambahin satu tombol kecil di halaman ‘Tentang Saya’, tapi prosesnya puanjaaaaaaaang banget. Buat yang udah terbiasa pakai Gitflow harusnya relate sih.

Kalian harus bikin branch baru dulu, kasih nama yang bener (feature/add-button-about-me), terus coding dikiiiit, commit, checkout lagi ke branch develop, merge, resolve conflict kalo ada (padahal yang ngoding cuma kita sendiri 🤕), baru deh merge lagi ke branch main buat rilis.

Panjang, kan? Capek pula wkwk.

Sebagai developer, rasanya kita sering banget terjebak sama dogma “Best Practice”. Apalagi kalau baru aja tau Best Practice tertentu, pasti pengennya dipake terus—wajar juga sih, bagian dari belajar biar gak lupa. Contohnya GitFlow. Saya pertama kali tau itu behh, langsung ngerasa Gitflow itu adalah shirotol mustaqim dalam men-develop aplikasi 😅. Track git graph yang warna-warni kayak jalan kereta yang meliuk-liuk, udah biasa dijadiin keren-kerenan pas lagi nge-develop. Kayak punya mainan baru, haha.

“Kalau nggak pake Gitflow, pasti codingan lu berantakan,” gitu kira-kira suara-suara di kepala.

Tapi barusan, saya kepikiran ulang. Apakah struktur serumit itu beneran relevan buat proyek hirahmat.dev yang saya kerjain sendirian? Apakah beneran saya butuh birokrasi branch release/0.1.0 padahal yang nentuin kapan rilis ya saya sendiri juga?

Akhirnya, saya rombak total cara saya nge-manage kode di website ini. Selamat tinggal Gitflow, selamat datang Trunk-Based Development.

Jebakan “Best Practice” yang Nggak Selalu Best

Sebelumnya, saya termasuk yang taat sama aturan Gitflow, pertama kali tau itu di Kulina, tempat aktif kerja saya sampai sekarang. Alur nge-develop aplikasi saya bener-bener textbook Gitflow abizz. Mau itu proyek kerja sama tim maupun proyek sendiri. Keliatannya profesional banget, rapi emang. Tapi, kalau buat proyek yang dikerjain sendiri pakai Gitflow, jadinya malah bikin frustasi. Jadi menurut saya kurang cocok.

Sering kejadian, saya lagi asik coding di branch fitur tertentu, terus tiba-tiba ada ide lain. Tanpa saya sadar saya coding ide itu di branch yang sama. Pas mau commit, “Waduh, ini branch feature/A, kok isinya ada kodingan buat fitur B ya?”. Akhirnya harus stash dulu, pindah branch, pop stash… ribet.

Belum lagi soal deployment—inget ya, keresahan ini cuma muncul di proyek kecil dan kalo ngerjainnya sendirian tapi pakai Gitfllow.

Di Gitflow, proses merge dari develop ke main itu kan “sakral” ya, dan karena itu juga, suka males buat rilis update yang kecil-kecilan. Nunggu fiturnya numpuk dulu, biar rilis sekalian. Karena ritual yang panjang dan ribet itu.

Kelemahan lainnya, sekalinya rilis, kalau ada error, pusing nge-track-nya, karena perubahannya udah kebanyakan.

Buat tim besar yang isinya puluhan orang, Gitflow itu emang penyelamat. Dia ngebantu banget supaya kodingan si developer A nggak nindih kodingan si developer B. Tapi buat solo developer? Ibarat lu pake truk kontener cuma buat beli galon ke warung depan. Bisa sih, tapi ya ngapain 😌?

Balik ke Kesederhanaan: Trunk-Based Development

Setelah searching dan baca-baca, saya nemu konsep Trunk-Based Development (TBD). Filosofinya tuh bisa dibilang “zen” banget.

Cuma ada satu sumber kebenaran, yaitu branch main.

Udah, itu aja. Nggak ada lagi branch develop yang jadi tempat numpang kode setengah jadi. Nggak ada juga branch release yang dipakai cuma untuk nambah-nambahin step merge.

Alur development website saya sekarang bener-bener straightforward:

Mungkin ada yang kepikiran, “Lho, bahaya dong? Kalau langsung push ke main terus ada bug, website live-nya langsung rusak nanti?”

Nah, poin menariknya di sini. Justru karena “bahaya”, kita jadi dipaksa buat lebih disiplin. Solusinya bukan dengan nambah birokrasi branch, bla-bla-bla, dsb., tapi dengan Otomisasi.

Perkenalkan, Github Actions

Karena proyek ini proyek pribadi, dan dikerjain sendirian, ngapain harus capek-capek pull request segala buat nambah fitur dan minta review kode—ke diri sendiri 😅—sebelum deploy dan rilis.

Jadi, saya manfaatin sistem CI/CD (Continuous Integration/Continuous Deployment) sebagai gantinya. Github Actions.

Saya utak-atik settings vercel (tempat saya hosting web):

Pertama, push ke branch main nggak boleh nge-trigger deploy. Ini penting. Supaya bisa bebas push kode setengah jadi atau (work in progress) ke branch main buat backup ke cloud, jaga-jaga lagi ngoding, eh anak nangis minta temenin, simpel. Push aja udah nggak masalah.

Kedua, rilis itu harus disengaja. Saya pake git tag. Jadi pas saya ngerasa, “Kayaknya udah oke fitur ini, udah siap rilis,” saya tinggal ketik:

powershell
git tag v0.12.0
git push origin v0.12.0

Ketiga, biarin Github Actions yang urusin sisanya. Dia bakal download kode saya, install semua library (pnpm), dan build aplikasi. Kalau ada error dikit aja pas build, dia bakal kasih tau error-nya dan stop prosesnya. Website jadi aman.

Tapi kalau nggak ada error dan lancar, langsung dia kirim ke vercel hasil buildnya buat di-deploy ke Production.

Saya tinggal nonton doang dan nunggu.

Tools Itu Harusnya Memudahkan, Bukan Menyulitkan

Perubahan ini bener-bener ngerubah ritme kerja saya. Waktu yang tadinya abis buat ngurusin merge conflict dan gonta-ganti branch, sekarang bisa dipake buat beneran ngoding atau mikirin fitur atau desain yang lebih oke.

History Git saya juga jadi lurus, seneng bet liatnya. Nggak ada lagi cabang ruwet kayak kabel kusut.

Pelajaran terbesar sebenernya bukan soal teknis Git-nya. Tapi soal keberanian buat mempertanyakan standar. Nggak semua “best practice” cocok buat seluruh kasus dan konteks.

Buat temen-temen solo developer yang mungkin masih ngerasa “beban” sama alur kerjanya sendiri, coba evaluasi lagi. Jangan-jangan selama ini cuma ikut-ikutan standar industri tanpa mikir apakah itu beneran ngebantu kita atau nggak.

Kadang, cara yang paling sederhana itu justru cara yang paling efektif. Dan buat saya sekarang, kesederhanaan adalah kunci produktifvitas.