Delapan Orang, Satu Repository, Satu Alur Kerja
Menulis kode yang benar ternyata hanya separuh dari tantangan dalam membangun sebuah sistem. Tantangan lain yang ternyata perlu dihadapi adalah menyatukan kode dari beberapa orang yang bekerja secara paralel, dengan jadwal kuliah dan magang masing-masing, namun dengan tujuan yang sama yaitu membuat satu sistem yang utuh tanpa saling menimpa pekerjaan.
Di proyek kelompok kami, ini bukan hanya cerita saja. Repository kami private, hanya dapat diakses oleh tim kami sendiri, dan dengan belasan fitur yang dipecah jadi beberapa Product Backlog Item yang dikerjakan bersamaan, tanpa aturan main yang jelas, repository ini dapat dengan cepat berubah jadi tumpukan branch yang saling bertabrakan dan histori commit yang tidak dapat dibaca siapa pun, bahkan oleh kami sendiri di masa depan.
Maka dari itu saya menulis aturan bersama ini yang saya sebut sebagai “Our Rules”.
Satu Branch, Satu Tugas, Satu Nama yang Jelas
Setiap orang kerja di branch-nya sendiri, dengan format yang sama untuk semua orang.
Feat/PBI-X-NAME
Misalnya Feat/PBI-7-Rio, langsung kelihatan ini branch untuk PBI nomor 7 yang lagi dikerjain Rio. Jadi siapa pun di tim, tanpa perlu bertanya di grup, langsung tahu siapa lagi ngerjain apa cuma dari lihat daftar branch.
Begitu pekerjaannya selesai, baru branch itu di-Pull Request ke branch dev. Bukan langsung ke main. Ini kayak jaring pengaman, karena dev jadi tempat semua orang ketemu dan diintegrasikan dulu, sebelum sesuatu dianggap sudah siap dipakai.
Pull Request Bukan Sekadar Formalitas
Kami sepakat memakai format PR yang sama. Title-nya mengikuti pola, sebagai contoh feat: create generate buttonatau fix: resolve PDF rendering issue . Pada deskripsi pull request wajib menulis backlog spesifik apa saja yang dikerjakan, tidak hanya "update fitur", tapi dengan format:
# Linear Ticket Link:
# Solution:
# Screenshot: (if any)
Jadi kami wajib menempel link ticket Linear yang relevan, jelasin solusinya di bagian Solution, dan kalau ada perubahan visual, tempel screenshot-nya di bagian terakhir. Kelihatan kecil, tapi ini mengubah cara orang mereview dari baca kode dulu terus bayangin sendiri hasilnya, jadi lihat hasilnya dulu baru baca kodenya. Link Linear-nya juga bikin siapa pun yang review nggak perlu nebak-nebak PR ini ngerjain ticket yang mana, tinggal klik dan langsung ketemu konteksnya.
Get Cleo Excellen Iskandar’s stories in your inbox
Join Medium for free to get updates from this writer.
Setelah PR dibuat, kami wajib lapor ke grup dan tag everyone, biar siapa pun yang lagi available bisa langsung review, nggak nunggu satu orang tertentu yang mungkin lagi sibuk sama kerjaan lain atau magang. Namun hanya saya yang punya kewenangan klik tombol Merge. Semua orang boleh review, boleh komentar, boleh bantu benerin conflict punya teman, tapi keputusan akhir buat gabungin kode ke dev tetap lewat satu pintu. Bukan karena nggak percaya, tapi agar selalu ada satu orang yang tahu persis kondisi dev di titik mana pun, kalau-kalau ada yang harus di-rollback mendadak.
Commit Message Tidak Bisa Lagi Asal Tulis
Bagian yang menurut saya paling seru dibahas justru bukan yang manual, tapi yang otomatis.
Kami pakai Conventional Commits, format type(scope): subject, dan di tulis eksplisit di commitlint.config.js:
export default {
extends: ['@commitlint/config-conventional'],
rules: {
'type-enum': [2, 'always', ['feat','fix','style','refactor','perf','test','chore','ci','revert','db','wip']],
'scope-enum': [1, 'always', ['frontend','backend','shared','docker','auth','memos','budget','approval','notification','pdf','users','units','dispositions','attachments','prisma','ci','deps','config']],
'subject-case': [2, 'never', ['start-case', 'pascal-case', 'upper-case']],
'header-max-length': [2, 'always', 100],
'body-max-line-length': [1, 'always', 150],
},
}Angka 2 sama 1 itu level severity. 2 berarti error, commit langsung ditolak kalau melanggar. 1 cuma warning, tetap boleh lanjut namun dikasih peringatan. Jadi type itu wajib benar, harus salah satu dari feat, fix, dan seterusnya, sementara scope cuma disaranin sesuai daftar modul yang kami punya. Kalau ada modul baru yang belum masuk daftar, commit-nya tidak akan gagal, namun hanya ada peringatan.
Tapi aturan yang cuma ditulis di file konfigurasi itu percuma kalau tidak ada yang beneran menegakkan di momen yang tepat, yaitu ketika kami ingin melakukan commit, bukan ketika PR review. Di sinilah Husky masuk:
.husky/commit-msg → pnpm commitlint --edit "$1"
.husky/pre-commit → pnpm lint-stagedcommit-msg hook ini jalan otomatis tiap kali ada yang git commit. Sebelum commit-nya beneran terbuat, pesan commit-nya dicek dulu lewat commitlint. Kalau formatnya salah, misalnya lupa nulis type, atau subject-nya ditulis Title Case, commit langsung ditolak dengan pesan error di terminal, dan orang tersebut harus revisi dulu sebelum bisa lanjut.
Efeknya, nggak ada lagi commit message kayak “update”, “fix bug”, atau “asdasd” yang nyelip ke histori, karena penegakannya nggak bergantung disiplin masing-masing orang, tapi dipaksa sistem di titik paling awal, sebelum kesalahan itu sempat tersimpan.
Kesimpulan
Branch naming yang konsisten membuat status pekerjaan tim lebih terlihat. Format PR yang seragam bikin proses review jadi lebih mudah dan cepat. Commit lint yang dipaksa Husky membuat histori kode tetap rapi dan gampang di-track, tanpa perlu semua orang untuk ingat aturan penulisan setiap saat.
Alat-alat ini tidak menggantikan komunikasi tim. Tapi mereka membuat repository ini tetap konsisten dan rapi dengan sendirinya, jadi kami tidak perlu mengingatkan satu sama lain terkait format penamaan atau cara menulis commit yang benar.
