Memilih Workflow yang Tepat

Delapan chapter sebelumnya memainkan delapan pola sampai perintah-perintahnya. Menyusun semuanya di satu kepala memunculkan pertanyaan yang lebih penting dari perintah mana pun: pola yang mana, untuk proyek yang seperti apa? Workflow kerap dipilih lewat peniruan, bukan penalaran — tim menyalin GitFlow penuh dari blog terkenal, memasang review lima orang untuk repository dua penulis, atau berganti pola tiap tahun karena yang baru terdengar modern. Pemilihan yang sehat jalan ke arah sebaliknya: mulai dari masalah nyata, ukur tim dan produknya, lalu ambil pola paling sederhana yang menjawab keduanya. Pro Git menyebutnya kesepakatan kerja tim, bukan fitur perangkat lunak — bab Distributed Workflows . Chapter penutup ini merangkai keputusan itu menjadi kerangka, matriks, dan alur yang bisa dibaca sekali sebelum memutuskan.

Empat Pertanyaan Pembuka #

Keputusan workflow dijawab dengan empat pertanyaan, dan urutannya menentukan karena jawaban pertama mempersempit yang berikutnya:

Ukuran tim yang dihitung adalah kontributor rutin pada satu repository, bukan jumlah karyawan. Satu orang menjawab semua sendirian — pola Workflow Proyek Pribadi cukup. Dua sampai lima orang saling kenal dan berbagi satu produk — Workflow Tim Kecil pas ukurannya. Enam ke atas menuntut pembagian wilayah dan pemilik per path — wilayah Trunk-Based Development dan CODEOWNERS.

Jenis produk menentukan ritme perubahan. Situs web yang deploy terus-menerus butuh jalur pendek: PR kecil, merge cepat. Produk yang rilis terjadwal dengan beberapa versi hidup bersamaan — plugin, aplikasi on-premise — butuh branch rilis dan jalur Workflow Hotfix . Proyek publik dengan kontributor asing menuntut Workflow Open Source . Tim yang produknya dokumen memakai Workflow Documentasi .

Dua pertanyaan terakhir menjadi faktor pengali. CI yang matang — membangun dan menguji setiap PR — membeli keberanian merge cepat; tanpa CI, gerbang manual harus menggantikan mesin. Budaya review menentukan gerbangnya hidup atau hanya seremonial: review satu orang yang benar-benar membaca lebih bernilai daripada tiga persetujuan sekilas.

Matriks Rekomendasi #

Kombinasi paling umum dipetakan berikut — tiap baris dibaca sebagai titik mulai, bukan vonis:

Kombinasi di luar tabel tetap terbaca: cari baris terdekat, lalu sesuaikan dengan faktor pengali. Tim tiga orang dengan CI matang boleh lebih longgar dari barisnya; tim lima orang tanpa CI sebaiknya lebih ketat.

Alur Keputusan #

Empat pertanyaan tadi bisa dilipat menjadi satu alur — tiga pertanyaan terbesar membentuk jalannya, CI dan budaya review menentukan ketat gerbang di tiap ujung:

Ujung setiap jalur bukan status permanen. Proyek pribadi mendapat kontributor kedua; rilis terjadwal memperpendek ritmenya — alur ini dijalankan ulang setiap kali keadaan berubah, dan boleh mundur ke pola lebih sederhana sama seperti naik ke yang lebih berat.

Tiga Anti-Pattern #

Tiga kebiasaan paling merusak muncul bukan karena kurangnya alat, melainkan cara memilihnya:

• Cargo-cult. Meniru pola tim lain tanpa memiliki masalah yang sama. GitFlow penuh di repository dua penulis menjawab pertanyaan yang tidak pernah ditanyakan siapa pun. Ujiannya satu kalimat: bila tidak bisa disebutkan pain apa yang dijawab sebuah aturan, aturan itu tiruan tanpa alasan.
• Ganti workflow berkala. Pola baru terdengar modern hampir tiap tahun, dan biayanya selalu nyata: tim belajar ulang, konvensi riwayat patah di tengah, tag rilis terbentuk dalam dua gaya. Workflow ditukar hanya ketika pain nyata muncul dan pola lama terbukti tak menjawabnya.
• Aturan tanpa dokumentasi alasan. “Review dua orang wajib” diwariskan tanpa catatan kenapa — dua tahun kemudian tak ada yang berani menghapusnya meski penyebabnya sudah hilang. Setiap aturan workflow dicatat lengkap dengan alasannya, persis pola berkas kontribusi di Workflow Documentasi .

Mulai Sederhana, Tambah Saat Nyeri #

Prinsip kerangka ini satu tarikan napas: mulai dari pola paling sederhana yang berfungsi, lalu tambahkan aturan hanya ketika nyeri nyata muncul — bukan ketika blog tim besar menyarankannya. Tim kecil sudah mengenal versi pendeknya: aturan baru layak ditambahkan hanya setelah masalah yang sama muncul dua kali. Tabel ini memetakan nyeri ke aturan yang sah dibelanya:

Aturan ditambah satu per satu, dan workflow yang sehat juga tahu menyusut: nyeri yang hilang membawa pulang aturan yang tak lagi dibela.

Rekap Delapan Workflow #

Sebelum melangkah, seluruh section terlipat dalam satu tabel:

Matriks, alur, dan rekap di atas adalah peta — dan peta baru terasa setiap langkah kaki ditaruh di wilayahnya. Section Proyek Git adalah wilayah berjalan kaki itu: tujuh proyek terpandu, dari repository pribadi, feature branch, kolaborasi remote, code review, pemulihan riwayat, hooks, sampai simulasi rilis lengkap — tiap proyek melanjutkan keadaan sebelumnya dan semuanya dikerjakan nyata dari nol. Di sanalah seluruh workflow yang baru saja kita petakan menemui proyek, tim, dan keputusan kita sendiri.