Git Workflow for Small Teams (Keep It Simple)

Selasa lalu, saya melihat seorang pengembang junior menghabiskan empat puluh lima menit mencoba mencari tahu mengapa cabang fitur mereka tidak dapat digabung. Penyebabnya? Alur kerja Git tim kami yang terlalu rumit, yang melibatkan empat jenis cabang berbeda, protokol rebase wajib, dan strategi merge yang memerlukan diagram alur untuk dipahami. Saya telah memimpin tim rekayasa selama dua belas tahun, dan saya dapat memberi tahu Anda dengan keyakinan mutlak: kebanyakan tim kecil tenggelam dalam kerumitan Git yang tidak mereka butuhkan.

Nama saya Sarah Chen, dan saya telah menghabiskan dekade terakhir membangun dan memperbesar tim pengembangan di tiga startup berbeda. Saya telah melihat tim yang terdiri dari lima pengembang menggunakan alur kerja yang dirancang untuk organisasi dengan lima ratus insinyur. Saya telah menyaksikan programer brilian membuang waktu berjam-jam untuk menavigasi strategi cabang yang tidak memberikan nilai tambah pada pekerjaan mereka yang sebenarnya. Dan saya telah belajar bahwa ketika datang ke alur kerja Git untuk tim kecil—katakanlah dua hingga sepuluh pengembang—kesederhanaan bukan hanya hal yang diinginkan. Ini adalah perbedaan antara mengirimkan fitur dan mengirimkan kebingungan.

Inilah yang tidak ada yang memberitahu Anda: Git sangat kuat, yang berarti itu juga sangat mudah untuk dipersulit. Internet penuh dengan artikel tentang Git-flow, GitHub flow, GitLab flow, pengembangan berbasis trunk, dan berbagai strategi lainnya. Kebanyakan dari mereka menyelesaikan masalah yang tidak Anda miliki. Saya akan menunjukkan kepada Anda alur kerja Git yang telah menjaga tim saya tetap produktif, bahagia, dan mengirimkan kode tanpa beban kerumitan tingkat perusahaan.

Mengapa Kebanyakan Alur Kerja Git Gagal untuk Tim Kecil

Sebelum kita menyelami apa yang berhasil, mari kita bicara tentang apa yang tidak berhasil. Saya telah mewarisi basis kode dari tim yang menggunakan Git-flow dengan cabang pengembangan, cabang rilis, cabang hotfix, dan cabang fitur. Untuk tim yang terdiri dari empat pengembang yang bekerja pada produk SaaS dengan rilis mingguan, ini adalah hal yang sangat berlebihan.

Masalah dengan alur kerja kompleks bukanlah bahwa mereka salah—ini karena mereka menyelesaikan masalah yang muncul pada skala besar. Git-flow diciptakan oleh Vincent Driessen pada tahun 2010 untuk konteks tertentu: tim yang mengelola beberapa versi produksi secara bersamaan, dengan siklus rilis yang panjang dan kebutuhan untuk manajemen hotfix yang luas. Jika Anda adalah tim kecil yang terus-menerus mengirimkan ke satu lingkungan produksi, Anda membawa semua beban dari Git-flow tanpa mendapatkan manfaatnya.

Saya melakukan eksperimen tahun lalu dengan dua tim yang memiliki ukuran dan tingkat kemahiran yang serupa. Tim A menggunakan alur kerja yang disederhanakan yang akan saya jelaskan. Tim B menggunakan Git-flow standar. Selama tiga bulan, Tim A mengirimkan 23% lebih banyak fitur dan melaporkan tingkat frustrasi yang jauh lebih rendah dalam survei triwulanan kami. Perbedaannya bukanlah bakat atau usaha—itu adalah gesekan. Setiap tipe cabang tambahan, setiap langkah merge tambahan, setiap operasi rebase kompleks menambah beban kognitif dan memperlambat tim Anda.

Tim kecil memiliki kendala yang berbeda dibandingkan dengan organisasi besar. Anda mungkin tidak memiliki manajer rilis yang didedikasikan. Anda kemungkinan tidak perlu mendukung beberapa versi produksi. Pengembang Anda melakukan beberapa peran dan sering berpindah konteks. Alur kerja Anda harus mencerminkan kenyataan ini, bukan melawannya. Ketika saya melihat tim yang terdiri dari lima orang menggunakan strategi Git yang sama seperti Google, saya tahu mereka mengoptimalkan untuk masalah yang mungkin mereka miliki suatu hari nanti alih-alih masalah yang mereka hadapi hari ini.

Biaya kerumitan bertambah seiring waktu. Seorang pengembang yang menghabiskan sepuluh menit per hari menavigasi alur kerja Git yang tidak perlu rumit kehilangan lebih dari empat puluh jam per tahun—satu minggu kerja penuh—hanya untuk mengelola cabang. Kalikan itu dengan tim Anda, dan Anda melihat minggu-minggu produktivitas yang hilang setiap tahun. Itu belum termasuk waktu yang dihabiskan untuk memperbaiki konflik merge yang tidak akan ada di alur kerja yang lebih sederhana, atau energi mental yang terkuras karena terus mengingat cabang mana yang harus digabung ke mana.

Filosofi Dua Cabang: Utama dan Fitur

Inilah alur kerja yang telah berhasil untuk setiap tim kecil yang saya pimpin: dua jenis cabang, itu saja. Anda memiliki cabang utama (atau master, jika Anda bekerja dengan repositori yang lebih lama), dan Anda memiliki cabang fitur. Itu saja. Tidak ada cabang pengembangan, tidak ada cabang rilis, tidak ada cabang hotfix. Hanya utama dan fitur.

Git sangat kuat, yang berarti itu juga sangat mudah untuk dipersulit. Sebagian besar tim sedang menyelesaikan masalah yang tidak mereka miliki.

Cabang utama Anda mewakili produksi. Apa pun yang ada di cabang utama harus dapat di-deploy kapan saja. Ini tidak dapat dinegosiasikan. Jika cabang utama tidak dapat di-deploy, alur kerja Anda telah gagal. Prinsip tunggal ini mengeliminasi sejumlah besar kerumitan karena berarti Anda selalu bekerja menuju target yang jelas: mendapatkan kode Anda ke dalam keadaan di mana ia dapat dengan aman digabung ke cabang utama.

Cabang fitur adalah tempat semua pekerjaan dilakukan. Memulai fitur baru? Buat cabang dari cabang utama. Memperbaiki bug? Buat cabang dari cabang utama. Merefactoring beberapa kode? Buat cabang dari cabang utama. Polanya konsisten dan dapat diprediksi. Tidak ada pohon keputusan tentang cabang mana yang harus digunakan sebagai dasar cabang atau cabang mana yang harus digabung. Setiap cabang fitur memiliki siklus hidup yang sama: cabang dari cabang utama, lakukan pekerjaan Anda, gabungkan kembali ke cabang utama.

Saya memberi nama cabang fitur dengan konvensi sederhana: tipe/deskripsi-singkat. Misalnya: fitur/autentikasi-pengguna, perbaikan-bug/redirect-login, refaktorisasi/klien-api. Prefiks tipe membuatnya segera jelas jenis pekerjaan yang sedang dilakukan, dan deskripsinya dapat dibaca manusia. Saya telah melihat tim menggunakan nomor tiket (fitur/JIRA-1234), tetapi saya merasa itu kurang intuitif ketika Anda melihat daftar cabang. Anda ingin dapat memindai cabang Anda dan segera memahami apa yang sedang dikerjakan.

Kecantikan pendekatan ini adalah prediktabilitasnya. Seorang pengembang baru yang bergabung dengan tim Anda dapat memahami seluruh alur kerja Git Anda dalam waktu sekitar lima menit. Tidak ada diagram cabang kompleks yang perlu dihafal, tidak ada kasus khusus yang harus diingat. Cabang dari cabang utama, lakukan pekerjaan Anda, gabungkan ke cabang utama. Kesederhanaan ini memiliki efek kompaun pada produktivitas. Ketika alur kerja Anda sederhana, pengembang menghabiskan lebih sedikit energi mental pada proses dan lebih banyak pada penyelesaian masalah yang sebenarnya.

Satu pertanyaan yang sering saya dapatkan: bagaimana dengan fitur yang berjalan lama yang memerlukan waktu mingguan untuk diselesaikan? Apakah Anda tidak memerlukan cabang pengembangan untuk itu? Tidak. Anda memerlukan fitur flag. Jika suatu fitur belum siap untuk pengguna, sembunyikan di balik sebuah flag. Ini menjaga kode Anda terintegrasi secara terus-menerus sambil memberi Anda kontrol atas kapan fitur menjadi terlihat. Saya telah melihat tim membuat strategi cabang yang rumit untuk menyelesaikan masalah yang lebih elegan diselesaikan oleh fitur flag.

Pull Requests: Gerbang Kualitas Anda

Setiap cabang fitur digabung ke cabang utama melalui pull request. Tidak ada pengecualian. Saya tidak peduli apakah Anda adalah CTO atau hanya perubahan satu baris. Pull requests tidak hanya tentang tinjauan kode—ini tentang menciptakan momen pengambilan keputusan yang disengaja sebelum kode masuk ke produksi.

Inilah template pull request saya, yang telah saya perbaiki melalui tahun-tahun eksperimen. Ini singkat karena template yang panjang tidak diisi dengan baik. Setiap pull request harus mencakup: deskripsi singkat tentang apa yang berubah, mengapa itu berubah, dan bagaimana cara mengujinya. Itu saja. Tiga bagian, masing-masing biasanya tiga hingga lima kalimat. Jika Anda tidak dapat menjelaskan perubahan Anda dalam ruang itu, maka perubahan Anda mungkin terlalu besar.

Untuk tinjauan kode, saya mengikuti aturan sederhana: setiap pull request memerlukan setidaknya satu persetujuan sebelum digabung, tetapi orang yang menyetujuinya berbagi tanggung jawab untuk masalah yang mungkin muncul. Ini menciptakan struktur insentif yang tepat. Peninjau mengambil peran mereka dengan serius karena mereka tidak hanya menandatangani—mereka juga ikut menandatangani. Pada saat yang sama, satu persetujuan sudah cukup karena kami adalah tim kecil dan saling percaya. Memerlukan dua atau tiga persetujuan mungkin masuk akal untuk tim yang terdiri dari lima puluh orang, tetapi bagi tim yang terdiri dari lima orang, itu hanya memperlambat semuanya.

Saya telah bereksperimen dengan berbagai harapan waktu putar tinjauan. Apa yang paling berhasil: peninjau harus memberikan umpan balik dalam waktu empat jam selama jam kerja. Bukan empat jam waktu tinjauan yang fokus—empat jam untuk setidaknya mengakui pull request dan memberikan umpan balik awal. Ini menjaga kode tetap bergerak tanpa menciptakan harapan respons instan. Jika seseorang membutuhkan lebih banyak waktu untuk tinjauan yang mendalam, mereka memberi tahu dengan mengomentari, dan penulis tahu untuk mengharapkan umpan balik yang mendetail nanti.

Satu praktik yang secara dramatis meningkatkan kualitas kode kami: meminta penulis pull request untuk menggabungkan kode mereka sendiri setelah disetujui. Ini tampaknya detail kecil, tetapi ini mengubah perilaku. Ketika Anda tahu Anda akan menjadi orang yang mengklik tombol gabung, Anda akan lebih berhati-hati tentang perubahan Anda. Anda