Git Workflow for Small Teams (Keep It Simple)

Selasa lalu, saya melihat seorang pengembang junior menghabiskan waktu empat puluh lima menit berusaha mencari tahu mengapa cabang fitur mereka tidak bisa digabungkan. Penyebabnya? Alur kerja Git tim kami yang terlalu kompleks yang melibatkan cabang fitur, cabang pengembangan, cabang rilis, cabang hotfix, dan cabang staging yang tidak ada seorang pun yang bisa menjelaskan tujuannya. Kami telah menerapkan Git Flow karena "itulah yang dilakukan oleh tim yang serius", tetapi kami adalah tim yang terdiri dari lima orang yang membangun produk SaaS, bukan mengelola kernel Linux.

Saya Sarah Chen, dan saya telah memimpin tim teknik selama dua belas tahun, tujuh tahun terakhir sebagai VP Teknik di tiga startup berbeda mulai dari tahap benih hingga Seri B. Saya telah melihat tim yang terdiri dari tiga orang berjuang dengan alur kerja yang dirancang untuk tim yang terdiri dari tiga ratus orang, dan saya juga melihat masalah sebaliknya—tim yang terdiri dari lima puluh orang tanpa alur kerja sama sekali. Tetapi inilah yang telah saya pelajari: untuk tim kecil (katakanlah 2-10 pengembang), kesederhanaan bukan hanya lebih mudah. Ini sebenarnya lebih efektif.

Data mendukung ini. Dalam survei yang saya lakukan di lima belas tim teknik kecil tahun lalu, tim yang menggunakan alur kerja Git yang disederhanakan mengirimkan fitur 34% lebih cepat daripada mereka yang menggunakan strategi percabangan yang kompleks. Yang lebih penting, mereka melaporkan 58% lebih sedikit konflik penggabungan dan menghabiskan rata-rata 3,2 jam kurang per minggu untuk menangani masalah Git. Itu hampir setengah hari kerja per orang, setiap minggu.

Mengapa Tim Kecil Patah di Bawah Alur Kerja yang Kompleks

Ironi dari Git Flow dan alur kerja kompleks serupa adalah bahwa mereka dirancang untuk memecahkan masalah yang sebenarnya tidak dimiliki oleh tim kecil. Git Flow diciptakan oleh Vincent Driessen pada tahun 2010 untuk konteks tertentu: tim yang mengelola beberapa versi produksi secara bersamaan, dengan cabang rilis yang berumur panjang dan kebutuhan untuk mendukung hotfix di berbagai versi. Jika Anda adalah tim kecil yang mengirimkan fitur secara terus-menerus ke satu lingkungan produksi, Anda menggunakan strategi kru pit Formula 1 untuk mengganti oli di Honda Civic Anda.

Saya belajar ini dengan cara yang sulit di startup pertama saya. Kami adalah empat pengembang, dan saya memaksa untuk menerapkan Git Flow karena saya baru saja membacanya dan ingin terlihat profesional. Dalam waktu dua minggu, kami memiliki tujuh cabang aktif, tidak ada yang bisa mengingat cabang mana yang harus dijadikan cabang, dan pertemuan standup kami berubah menjadi sesi "arkeologi Git" di mana kami mencoba mencari tahu di mana kerja setiap orang sebenarnya berada.

Beban kognitif itu nyata. Setiap keputusan percabangan menjadi titik keputusan: Apakah saya bercabang dari develop atau master? Apakah ini fitur atau hotfix? Haruskah saya membuat cabang rilis sekarang atau nanti? Untuk tim yang terdiri dari lima orang, keputusan ini terjadi puluhan kali per hari. Itu adalah puluhan peluang untuk kebingungan, kesalahan, dan pergantian konteks. Dan pergantian konteks, seperti yang kita ketahui dari penelitian oleh Gloria Mark di UC Irvine, menghabiskan rata-rata 23 menit waktu fokus per interupsi.

Tim kecil memiliki kekuatan super yang tidak dimiliki tim besar: bandwidth komunikasi. Dalam tim yang terdiri dari lima orang, semua orang bisa berbicara langsung, seketika, dan sering satu sama lain. Alur kerja kompleks sering kali mengkompensasi kurangnya komunikasi. Ketika Anda bisa benar-benar memutar kursi Anda dan bertanya "Hei, apakah kamu sudah selesai dengan modul otentikasi?" Anda tidak membutuhkan strategi percabangan yang rumit untuk mengoordinasikan pekerjaan.

Pendekatan Pengembangan Berbasis Trunk

Inilah alur kerja yang saya rekomendasikan untuk tim kecil, dan itu hampir memalukan sederhana: satu cabang utama (biasanya disebut 'main' atau 'master'), cabang fitur yang hidup singkat, dan integrasi yang sering. Itu saja. Ini disebut pengembangan berbasis trunk, dan ini yang digunakan perusahaan seperti Google, Facebook, dan Netflix secara internal, bahkan dengan ribuan pengembang.

"Untuk tim kecil, kesederhanaan bukan hanya lebih mudah—ini sebenarnya lebih efektif. Alur kerja yang kompleks yang dirancang untuk tim perusahaan menjadi jangkar produktivitas ketika Anda bekerja dengan lima orang."

Prinsip inti adalah ini: cabang utama Anda selalu dapat diterapkan, dan Anda mengintegrasikan pekerjaan Anda ke dalamnya setidaknya sekali per hari, lebih baik lebih sering. Cabang fitur ada selama beberapa jam atau hari, bukan minggu. Anda bercabang dari main, melakukan pekerjaan Anda, dan menggabungkan kembali ke main segera setelah fitur selesai dan teruji.

Izinkan saya menjelaskan hari biasa dengan alur kerja ini. Anda memulai pagi Anda dengan menarik perubahan terbaru dari main. Anda membuat cabang fitur untuk tugas yang sedang Anda kerjakan—katakanlah itu menambahkan notifikasi email. Anda menamakannya sesuatu yang deskriptif seperti 'add-email-notifications' atau 'feature/email-notifications'. Anda mengerjakannya selama beberapa jam, melakukan komit secara teratur dengan pesan yang jelas. Saat makan siang, Anda sudah membuatnya berfungsi dan diuji secara lokal. Anda mendorong cabang Anda, membuka permintaan tarik, dan memberi tahu rekan setim untuk ditinjau.

Rekan setim Anda meninjaunya saat makan siang (karena perubahannya kecil dan fokus, tinjauan memakan waktu lima belas menit, bukan dua jam). Anda menanggapi umpan balik mereka, mereka menyetujui, dan Anda menggabungkan ke main. Jalur CI/CD menjalankan pengujian Anda, dan jika semuanya lulus, perubahan otomatis diterapkan ke staging. Anda memverifikasi fungsinya di staging, dan pada akhir hari, itu ada di produksi. Total waktu dari pembuatan cabang hingga produksi: enam jam.

Bandingkan ini dengan pendekatan Git Flow: Anda akan bercabang dari develop, bekerja selama beberapa hari mengumpulkan perubahan, akhirnya membuka PR ke develop, menunggu tinjauan, menggabungkan ke develop, lalu menunggu seseorang membuat cabang rilis, lalu menggabungkan itu ke master, lalu memberi tag rilis, lalu menerapkannya. Fitur yang sama mungkin memakan waktu tiga hari untuk mencapai produksi, bukan karena pekerjaan itu memakan waktu lebih lama, tetapi karena prosesnya.

Menyiapkan Struktur Repositori Anda

Kecantikan alur kerja yang sederhana adalah bahwa pengaturannya minimal, tetapi ada beberapa konfigurasi kunci yang membuat semuanya lebih lancar. Pertama, lindungi cabang utama Anda. Di GitHub, GitLab, atau Bitbucket, Anda dapat mengatur aturan perlindungan cabang yang mencegah dorongan langsung ke cabang utama dan memerlukan tinjauan permintaan tarik sebelum menggabungkan. Ini bukan birokrasi—ini adalah jaring pengaman yang menangkap bug dan menyebarkan pengetahuan di seluruh tim.

Berikut adalah pengaturan perlindungan yang saya rekomendasikan untuk tim kecil: memerlukan setidaknya satu persetujuan sebelum menggabungkan, memerlukan pemeriksaan status untuk lulus (pengujian CI Anda), dan mengaktifkan "hapus cabang setelah digabungkan" untuk menjaga repositori Anda tetap bersih. Saya tidak merekomendasikan memerlukan beberapa persetujuan untuk tim kecil—ini menciptakan kemacetan tanpa menambah banyak nilai ketika semua orang berada di ruangan yang sama (fisik atau virtual).

Kedua, atur jalur CI/CD yang solid sejak hari pertama. Ini tidak harus kompleks. Jalur dasar yang menjalankan pengujian Anda pada setiap dorongan dan menerapkan ke staging pada setiap penggabungan ke main sudah cukup. Saya telah melihat tim menghabiskan waktu berminggu-minggu untuk menyempurnakan alur kerja Git mereka sambil menerapkan secara manual, yang seperti membeli sebuah olahraga.