Git Workflow Best Practices for Teams - cod-ai.com

Tiga tahun yang lalu, saya melihat seorang pengembang senior di sebuah perusahaan Fortune 500 menghabiskan empat jam untuk menyelesaikan konflik penggabungan yang seharusnya tidak ada. Pelakunya? Tim yang terdiri dari 12 insinyur yang semuanya berkomitmen langsung ke master tanpa workflow yang disepakati. Insiden tunggal itu menghabiskan biaya perusahaan sekitar $2,400 dalam waktu pengembang, dan itu jauh dari kasus yang terisolasi. Saya Marcus Chen, dan saya telah menghabiskan 11 tahun terakhir sebagai arsitek DevOps membantu tim mulai dari startup yang semangat hingga raksasa perusahaan mengoptimalkan alur kerja pengembangan mereka. Apa yang saya pelajari adalah bahwa Git itu sendiri tidak rumit—cara tim menggunakan Git yang menentukan apakah mereka dapat mengirim dengan cepat atau terjebak dalam kekacauan.

Perbedaan antara tim rekayasa berkinerja tinggi dan yang selalu memadamkan api sering kali terletak pada alur kerja Git mereka. Menurut survei 2023 oleh GitLab, tim dengan alur kerja Git yang terdefinisi dengan baik mengirimkan 46% lebih sering dan mengalami 60% lebih sedikit insiden produksi. Namun, sebagian besar tim yang saya konsultasikan masih mengandalkan keberuntungan, memperlakukan Git seperti sistem cadangan sederhana daripada alat kolaborasi yang kuat.

Mengapa Alur Kerja Git Anda Lebih Penting Dari yang Anda Pikirkan

Izinkan saya memberi Anda gambaran. Pada tahun 2019, saya bergabung dengan startup fintech sebagai karyawan DevOps pertama mereka. Mereka memiliki 8 pengembang, semuanya berbakat, semuanya merasa frustrasi. Frekuensi penerapan mereka telah turun dari dua kali seminggu menjadi sekali setiap tiga minggu. Tinjauan kode memakan waktu berhari-hari. Hotfix menjadi mimpi buruk. Ketika saya menyelami sejarah Git mereka, saya menemukan penyebab utamanya: mereka tidak memiliki alur kerja sama sekali.

Para pengembang menciptakan cabang dengan nama seperti "perbaiki-sesuatu" dan "pembaruan-john." Beberapa komit langsung masuk ke master. Yang lain tersimpan di cabang selama berminggu-minggu. Tidak ada proses yang jelas untuk tinjauan kode, tidak ada standar untuk pesan komit, dan tentu saja tidak ada automasi di sekitar operasi Git mereka. Beban kognitif hanya untuk memahami apa yang terjadi di repositori menghabiskan waktu berjam-jam setiap hari.

Berikut adalah yang kebanyakan orang lewatkan: alur kerja Git bukan hanya tentang kontrol versi. Ini tentang komunikasi, koordinasi, dan menciptakan model mental yang dibagikan tentang bagaimana kode berpindah dari ide ke produksi. Jika dilakukan dengan benar, alur kerja Git Anda menjadi infrastruktur yang tak terlihat yang memungkinkan pengembang fokus pada menulis kode alih-alih mengelola kekacauan.

Dampaknya dapat diukur. Setelah menerapkan alur kerja terstruktur di startup fintech itu, kami melihat frekuensi penerapan kembali ke dua kali seminggu dalam waktu sebulan, dan akhirnya mencapai penerapan harian dalam enam bulan. Waktu tinjauan kode turun dari rata-rata 3,2 hari menjadi 8 jam. Skor kepuasan pengembang melonjak 34 poin. Dan ini yang mengejutkan: kami tidak merekrut lebih banyak orang atau mengubah tumpukan teknologi kami. Kami hanya sepakat tentang bagaimana menggunakan Git.

Memilih Model Alur Kerja yang Tepat untuk Tim Anda

Tidak ada alur kerja Git yang cocok untuk semua situasi, dan siapa pun yang memberi tahu Anda sebaliknya sedang menjual sesuatu. Selama karir saya, saya telah menerapkan variasi dari setiap model alur kerja besar, dan masing-masing memiliki tempatnya. Kuncinya adalah mencocokkan alur kerja dengan ukuran tim, frekuensi rilis, dan toleransi risiko Anda.

"Alur kerja Git bukan hanya tentang kontrol versi—ini tentang mengurangi beban kognitif, memungkinkan pengembangan paralel, dan menciptakan bahasa bersama tentang bagaimana tim Anda mengirim kode."

Untuk tim kecil (2-5 pengembang) yang bekerja pada produk dengan penerapan berkelanjutan, saya biasanya merekomendasikan pendekatan pengembangan berbasis trunk yang disederhanakan. Para pengembang bekerja pada cabang fitur yang memiliki masa hidup singkat, yang hidup selama beberapa jam atau paling lama beberapa hari, kemudian bergabung langsung ke main setelah ditinjau. Ini menjaga basis kode tetap segar dan secara dramatis mengurangi konflik penggabungan. Saya berhasil menggunakan ini dengan tim beranggotakan 4 orang yang membangun platform analitik SaaS—kami mempertahankan rata-rata masa hidup cabang 4 jam dan menerapkan 3-4 kali sehari.

Tim menengah (6-20 pengembang) sering mendapat manfaat dari GitHub Flow atau alur kerja berbasis permintaan tarik yang serupa. Ini menambahkan lebih banyak struktur di sekitar tinjauan kode dan pengujian tanpa kompleksitas beberapa cabang yang hidup lama. Di sebuah perusahaan teknologi kesehatan dengan 14 pengembang, kami menggunakan GitHub Flow dengan sedikit perubahan: setiap permintaan tarik memerlukan dua persetujuan dan harus lulus serangkaian uji otomatis berdurasi 15 menit. Ini memberi kami keamanan yang kami butuhkan untuk kepatuhan HIPAA sambil mempertahankan waktu rata-rata 2 hari dari penciptaan cabang hingga produksi.

Tim yang lebih besar atau yang memiliki rilis terjadwal mungkin memerlukan Git Flow atau varian khusus. Saya bekerja dengan tim yang terdiri dari 45 pengembang di sebuah perusahaan e-commerce yang rilis setiap dua minggu. Kami menggunakan Git Flow yang dimodifikasi dengan cabang develop, release, dan master, ditambah cabang fitur untuk semuanya. Ya, itu lebih kompleks, tetapi memberi kami kontrol yang kami butuhkan untuk mengoordinasikan pekerjaan di beberapa tim dan mempertahankan jadwal rilis yang stabil.

Kesalahan terburuk yang saya lihat tim lakukan adalah mengadopsi alur kerja dari posting blog tanpa mempertimbangkan konteks mereka. Alur kerja yang sangat baik untuk tim beranggotakan 200 orang di Google mungkin berlebihan—atau tidak mencukupi—untuk startup beranggotakan 8 orang Anda. Mulailah dengan sederhana, ukur apa yang penting (frekuensi penerapan, waktu tunggu, tingkat kegagalan perubahan), dan kembangkan alur kerja Anda berdasarkan titik nyeri nyata, bukan yang teoretis.

Konvensi Penamaan Cabang yang Sebenarnya Berfungsi

Ini mungkin terdengar sepele, tetapi penamaan cabang yang tidak konsisten adalah salah satu dari tiga masalah alur kerja teratas yang saya temui. Ketika repositori Anda memiliki cabang bernama "uji," "fitur-baru," "perbaikan," "cabang-john," dan "PERBAIKAN-URGENT-JANGAN-HAPUS," Anda telah kalah sebelum Anda memulai.

Konvensi penamaan cabang yang baik memiliki banyak tujuan: membuat repositori mudah dibaca, memungkinkan automasi, dan mengkomunikasikan maksud. Berikut adalah sistem yang telah saya haluskan melalui puluhan implementasi: tipe/deskripsi-tiket. Misalnya: "fitur/AUTH-123-integrasi-oauth" atau "perbaikan/PROD-456-waktu-tunggu-pembayaran."

Prefix tipe (fitur, perbaikan, hotfix, refactor, dokumen) memungkinkan Anda dan alat Anda segera memahami tujuan cabang tersebut. Nomor tiket menghubungkan kode dengan sistem manajemen proyek Anda, menciptakan keterlacakan. Deskripsi membuat cabang dapat dibaca oleh manusia. Pola sederhana ini telah menghemat banyak jam kebingungan di setiap tim yang pernah saya kerjakan.

Di sebuah perusahaan, kami membawa ini lebih jauh dengan automasi. Sistem CI kami secara otomatis menerapkan berbagai suite pengujian berdasarkan prefix cabang—cabang fitur menjalankan seluruh suite, cabang perbaikan menjalankan pengujian yang ditargetkan, dokumen...