The Git Workflow That Actually Works for Solo Developers [Bahasa]

# Alur Kerja Git yang Sebenarnya Bermanfaat untuk Pengembang Solo Saya masih ingat momen tepat saya mengalami kebuntuan. Saat itu pukul 2 pagi pada hari Selasa, dan saya sedang memandangi konflik penggabungan antara cabang `feature/redesign` saya dan `main`. Yang lebih menggigit? Saya adalah satu-satunya pengembang di proyek tersebut. Saya benar-benar terjebak dalam konflik penggabungan dengan diri saya sendiri. Tiga hari kerja—hilang. Bukan karena kegagalan hard drive yang katastrofik atau repositori yang terhapus. Tidak, saya kehilangan tiga hari itu karena saya secara religius mengikuti alur kerja Git yang dirancang untuk tim yang beranggotakan lebih dari 10 pengembang. Saya memiliki cabang fitur, cabang hotfix, cabang rilis, dan cabang `develop` yang ada hanya untuk membuat saya merasa profesional. Ironi itu tidak hilang dari pandangan saya: saya menghabiskan lebih banyak waktu mengelola Git daripada benar-benar menulis kode. Malam itu, duduk di kantor rumah saya dengan kopi dingin dan ego yang terluka, saya membuat sebuah keputusan. Saya akan menghapus setiap elemen seremonial Git yang tidak berguna bagi saya sebagai pengembang solo. Tidak akan ada lagi alur kerja tim yang kaku. Tidak ada lagi berpura-pura saya membutuhkan infrastruktur yang sama seperti tim teknik beranggotakan 50 orang. Apa yang muncul dari frustrasi itu adalah alur kerja yang telah saya gunakan untuk mengirim lebih dari 40 proyek solo sejak saat itu. Ini tidak menarik. Tidak akan mengesankan siapa pun di konferensi teknologi. Tapi ini berhasil, dan lebih penting lagi, ini tidak menghalangi saya untuk benar-benar membangun sesuatu.

Mengapa Sebagian Besar Alur Kerja Git Gagal untuk Pengembang Solo

Masalah dengan sebagian besar tutorial dan alur kerja Git adalah bahwa mereka ditulis oleh orang-orang yang bekerja di perusahaan dengan banyak tim, proses tinjauan kode, dan jalur penyebaran yang melibatkan setidaknya tiga lingkungan yang berbeda. Ketika Anda adalah pengembang solo, Anda tidak memiliki batasan tersebut—tetapi Anda juga tidak memiliki jaring pengaman itu. GitFlow, alur kerja yang mendominasi tahun 2010-an, adalah contoh yang sempurna. Ini dirancang oleh Vincent Driessen untuk masalah tertentu: mengelola rilis untuk perangkat lunak yang perlu mendukung beberapa versi secara bersamaan. Jika Anda sedang membangun aplikasi desktop yang diinstal secara lokal oleh pelanggan, GitFlow masuk akal. Jika Anda adalah pengembang solo yang mengirim produk SaaS atau situs web klien, ini terlalu berlebihan. Perjalanan pengembang solo yang khas dengan Git berjalan seperti ini: Anda mulai dengan hanya melakukan commit ke `main` (atau `master`, tergantung kapan Anda belajar Git). Kemudian Anda membaca artikel tentang "alur kerja Git profesional" dan merasa bersalah. Anda mengimplementasikan cabang fitur. Kemudian Anda menambahkan cabang `develop` karena itulah yang ditunjukkan diagram. Dalam waktu singkat, Anda menghabiskan 20 menit sehari hanya untuk mengelola cabang, dan Anda bahkan tidak yakin mengapa setengah dari cabang itu ada. Saya telah ada di sana. Saya memiliki repositori dengan cabang bernama `feature/new-feature`, `feature/new-feature-2`, `feature/new-feature-actually-final`, dan `feature/new-feature-for-real-this-time`. Jika Anda belum pernah mengalami krisis penamaan cabang, Anda either berbohong atau Anda belum cukup lama mengembangkan secara solo. Masalah mendasar adalah bahwa alur kerja tim dirancang untuk menyelesaikan masalah tim: mengkoordinasikan kerja antara banyak orang, mencegah konflik, mengelola proses tinjauan kode, dan menjaga stabilitas di lingkungan yang dibagikan. Ketika Anda bekerja solo, sebagian besar masalah ini tidak ada. Anda tidak dapat mengalami konflik penggabungan dengan orang lain jika tidak ada orang lain.

Aturan Tiga Commit yang Mengubah Segalanya

Setelah bencana saya pukul 2 pagi, saya mulai menganalisis pola kerja saya yang sebenarnya. Saya mengangkat riwayat Git saya selama enam bulan sebelumnya dan melihat setiap cabang yang telah saya buat, setiap penggabungan yang telah saya lakukan, dan setiap konflik yang telah saya selesaikan. Apa yang saya temukan sangat iluminatif. Sembilan puluh persen dari cabang fitur saya mengandung tiga commit atau lebih sedikit sebelum digabungkan. Ini bukan fitur kompleks yang memerlukan isolasi selama berminggu-minggu. Ini adalah perbaikan kecil, perbaikan bug, dan perubahan bertahap yang saya pisahkan secara artifisial ke dalam cabang karena saya pikir itulah yang dilakukan oleh "pengembang sejati." Sepuluh persen sisanya—fitur kompleks yang sebenarnya—adalah di mana cabang itu masuk akal. Tetapi bahkan kemudian, saya memperhatikan sesuatu: cabang yang menyebabkan masalah adalah cabang yang saya biarkan terbuka selama lebih dari seminggu. Semakin lama cabang ada, semakin besar kemungkinan untuk menyebabkan masalah saat digabungkan kembali. Ini mengarah pada apa yang saya sebut Aturan Tiga Commit: Jika suatu perubahan memerlukan lebih dari tiga commit, itu mungkin terlalu besar dan harus dipecah. Jika tidak dapat dipecah, itu adalah salah satu dari sedikit kasus di mana suatu cabang benar-benar membantu. Aturan ini memaksa saya untuk berpikir berbeda tentang bagaimana saya bekerja. Alih-alih membuat cabang untuk "desain ulang seluruh UI," saya akan membuat cabang untuk "perbarui gaya tombol" atau "implementasikan komponen navigasi baru." Setiap cabang hidup selama satu atau dua hari maksimum, mengandung perubahan yang fokus, dan menggabungkan dengan bersih. Perubahan psikologisnya sangat signifikan. Saya berhenti berpikir dalam hal "fitur" dan mulai berpikir dalam hal "inkremen yang dapat diterapkan." Setiap cabang harus mewakili sesuatu yang bisa saya kirim ke produksi tanpa merusak fungsionalitas yang ada. Ini secara alami menjaga agar cabang tetap kecil dan hidup singkat.

Hari Ketika Saya Mengirim Bug ke Produksi (Dan Mengapa Itu Membuat Alur Kerja Saya Lebih Baik)

Izinkan saya menceritakan tentang penyebaran terburuk dalam karir saya. Saya sedang mengerjakan proyek klien—sistem pemesanan untuk jaringan hotel kecil. Saya telah bekerja pada cabang fitur selama dua minggu (ya, saya tahu, saya melanggar aturan saya sendiri) yang menambahkan integrasi pembayaran baru. Cabang tersebut telah menyimpang secara signifikan dari `main`. Saya begitu fokus pada fitur pembayaran sehingga saya tidak mengikuti perbaikan kecil dan peningkatan yang saya lakukan langsung ke `main` untuk permintaan mendesak dari klien. Ketika tiba waktunya untuk digabungkan, saya memiliki konflik di 14 file. Saya menyelesaikan konflik tersebut, menjalankan tes (dan tesnya lulus), dan mengdeploy ke produksi. Dalam satu jam, saya menerima telepon panik dari klien. Formulir pemesanan telah rusak. Bukan integrasi pembayaran baru—formulir pemesanan dasar yang sudah berfungsi dengan baik selama berbulan-bulan. Apa yang terjadi? Dalam menyelesaikan salah satu konflik penggabungan, saya secara tidak sengaja menyimpan versi salah dari sebuah fungsi. Tes tidak menangkapnya karena saya belum menulis tes untuk kasus tepi tertentu itu (pelajaran yang dipelajari). Bug itu sepenuhnya kesalahan saya, tetapi alur kerja telah memudahkan untuk melakukan kesalahan itu. Kejadian itu mengajarkan saya sesuatu yang krusial: sebagai pengembang solo, risiko terbesar saya bukanlah kode orang lain—melainkan kode saya sendiri dari dua minggu yang lalu. Ketika saya beralih konteks antara bagian-bagian berbeda dari proyek, saya pada dasarnya bekerja sama dengan versi saya di masa lalu. Dan diri saya yang dulu seringkali adalah rekan kerja yang tidak dapat diandalkan. Pencerahan ini mengarah pada pilar kedua dari alur kerja saya: Aturan Satu Minggu. Tidak ada cabang yang hidup lebih dari satu minggu. Jika suatu fitur akan memakan waktu lebih lama dari itu, saya memecahnya menjadi bagian-bagian kecil yang masing-masing dapat diselesaikan dan digabungkan dalam satu minggu. Jika itu tidak mungkin, saya menggunakan pengatur fitur untuk menggabungkan kode yang belum lengkap ke `main` sembari menyembunyikannya dari pengguna. Aturan Satu Minggu telah menyelamatkan saya berkali-kali. Ini memaksa saya untuk tetap dekat dengan `main`, yang berarti saya selalu bekerja dengan versi paling terkini dari basis kode. Ini mencegah jenis penyimpangan yang menyebabkan konflik penggabungan yang kompleks. Dan ini membuat saya jujur tentang ruang lingkup—jika saya tidak bisa menyelesaikan sesuatu dalam seminggu, saya mungkin mencoba melakukan terlalu banyak sekaligus.

Biaya Nyata dari Kompleksitas Cabang

Mari kita bicarakan angka. Saya melacak aktivitas terkait Git saya selama tiga bulan sebelum dan setelah menyederhanakan alur kerja saya. Hasilnya mencolok:

Kegiatan	Sebelum (jam/minggu)	Setelah (jam/minggu)	Waktu yang Dihemat
Membuat dan mengelola cabang	2.5	0.5	2 jam
Menyelesaikan konflik penggabungan	3.0	0.3	2.7 jam
Memutuskan cabang mana yang akan dikerjakan	1.5	0.1	1.4 jam
Membersihkan cabang yang kadaluarsa	1.0	0.1	0.9 jam
Rebasing dan menyinkronkan cabang	2.0	0.2	1.8 jam
Total overhead Git	10.0	1.2	8.8 jam

Hampir sembilan jam seminggu. Itu lebih dari satu hari kerja penuh yang saya habiskan pada upacara Git alih-alih menulis kode. Dalam setahun, itu lebih dari 450 jam—lebih dari 11 minggu kerja penuh. Tetapi penghematan waktu bahkan bukan manfaat yang paling signifikan. Yang benar-benar berubah adalah overhead mental saya. Sebelumnya, saya sering mendapati diri saya menatap terminal, berusaha mengingat cabang mana yang memiliki perubahan apa, apakah saya sudah menggabungkan sesuatu, atau jika saya perlu melakukan rebase sebelum menggabungkan. Pengambilan keputusan mikro ini menambah beban kognitif yang signifikan. Setelah menyederhanakan alur kerja saya, keputusan-keputusan tersebut menghilang. Saya selalu tahu di mana pekerjaan saya karena hanya ada satu atau dua cabang maksimal. Saya tidak perlu memikirkan strategi rebase atau strategi penggabungan karena cabang-cabang itu begitu cepat mati sehingga konflik jarang terjadi. Data juga mengungkapkan sesuatu yang tidak saya harapkan: frekuensi commit saya meningkat sebesar 40%. Dengan sedikit gesekan dalam alur kerja saya, saya menjadi lebih sering melakukan commit, yang berarti commit yang lebih kecil dan lebih fokus. Ini membuat lebih mudah untuk memahami sejarah saya dan, jika perlu, membalikkan perubahan spesifik tanpa membatalkan banyak pekerjaan yang tidak terkait.

Mengapa "Commit Awal, Commit Sering" Salah untuk Pengembang Solo

Inilah pandangan yang kontroversial: nasihat untuk "commit awal, commit sering" sebenarnya merugikan bagi pengembang solo. Saya tahu ini bertentangan dengan kebijaksanaan konvensional, tetapi dengarkan saya.

Tujuan dari commit bukanlah untuk membuat catatan rinci tentang setiap ketukan kunci. Tujuannya adalah untuk menciptakan titik pemeriksaan yang bermakna yang menceritakan kisah tentang bagaimana kode Anda berkembang. Ketika Anda bekerja solo, Anda adalah satu-satunya orang yang perlu memahami itu.