Git pre-commit hook, sebuah skrip yang berjalan secara otomatis sebelum sebuah commit diselesaikan, telah menjadi titik pertentangan utama di kalangan pengembangan perangkat lunak. Dirancang untuk menangkap masalah seperti kesalahan pemformatan kode atau rahasia yang bocor sejak dini, hook ini dipuji oleh sebagian orang karena meningkatkan kualitas kode dan dikutuk oleh yang lain karena mengganggu alur kerja. Komunitas pengembang saat ini sedang terlibat dalam diskusi panas tentang apakah manfaat pre-commit hook lebih besar daripada potensinya untuk mengganggu dan memperlambat proses pengembangan.
Debat Besar Pre-Commit vs. Pre-Push
Sebuah garis patahan utama dalam diskusi komunitas berpusat pada kapan pemeriksaan otomatis harus dijalankan. Banyak pengembang merasa bahwa pre-commit hook mengganggu alur kerja alami mereka, terutama ketika mereka membuat commit kecil dan sering untuk menyimpan progres. Bagi pengembang ini, hook pre-push adalah kompromi yang jauh lebih disetujui. Hook ini memungkinkan mereka untuk melakukan commit dengan bebas selama pengembangan dan hanya memberlakukan pemeriksaan kualitas ketika mereka siap untuk membagikan pekerjaannya kepada orang lain. Hal ini mencegah putaran umpan balik CI yang terkenal, di mana seorang pengembang melakukan push kode hanya untuk membuat pipeline remote gagal beberapa menit kemudian pada masalah pemformatan sederhana yang seharusnya dapat ditangkap secara lokal.
Saya ingin nol penundaan pada commit. Pemeriksaan dapat dijalankan terhadap pull request di runner GitHub action; tidak ada alasan untuk memaksa saya menjalankannya di mesin saya.
Yang lain membantah ini dengan menunjukkan bahwa pre-push hook hanya menunda masalah, meninggalkan masalah yang lebih besar untuk ditemukan nanti. Mereka berargumen bahwa mendapatkan umpan balik lokal yang langsung lebih efisien daripada menunggu proses CI. Inti dari masalahnya tampaknya adalah pertukaran antara kelancaran alur kerja langsung dan efisiensi jangka panjang.
Bahaya Hook yang Lambat dan Suka Mencampuri
Ada konsensus kuat bahwa kecepatan sebuah hook sangat penting untuk penerimaannya. Jika sebuah hook membutuhkan waktu lebih dari beberapa detik untuk dijalankan, ia menjadi sumber gesekan yang signifikan. Pengembang yang mengerjakan proyek besar melaporkan bahwa linter atau rangkaian pengujian yang lambat dalam pre-commit hook adalah alasan utama mereka menonaktifkannya. Kebijaksanaan komunitas menunjukkan bahwa setiap pemeriksaan yang memakan waktu lebih dari setengah detik adalah kandidat untuk dipindahkan ke hook pre-push, dan pengujian yang berjalan selama beberapa menit harus diserahkan sepenuhnya kepada sistem CI.
Poin pertentangan lainnya adalah hook yang memodifikasi kode, seperti auto-formatter. Sementara beberapa menghargai kenyamanannya, yang lain sangat menentang. Mereka berargumen bahwa memiliki skrip yang diam-diam mengubah pekerjaan Anda tanpa persetujuan eksplisit dapat membingungkan dan terkadang menyebabkan kode rusak. Preferensi bagi banyak orang adalah agar hook bersifat read-only; hook dapat menggagalkan sebuah commit, tetapi tidak boleh mengubah isinya.
Waktu dan Durasi Hook yang Direkomendasikan
| Tahap Hook | Pemeriksaan yang Direkomendasikan | Durasi Maksimal yang Direkomendasikan |
|---|---|---|
| Pre-Commit | Auto-formatting, pemindaian rahasia cepat | < 0,5 detik |
| Pre-Push | Linting cepat, pemeriksaan tipe, unit test | < 10 detik |
| CI Pipeline | Test suite lengkap, integration test, linter lambat | Menit hingga jam |
Rebase dan Masalah Hook
Diskusi yang lebih teknis, tetapi sama passionnya, berkisar pada bagaimana pre-commit hook berinteraksi dengan fitur rebase Git yang kuat. Ketika melakukan rebase pada serangkaian commit, pre-commit hook berjalan untuk setiap commit individual yang diputar ulang. Jika hook tersebut memformat kode secara otomatis, hal itu dapat memperkenalkan perubahan pemformatan pada setiap langkah, berpotensi menciptakan konflik gabungan di mana sebelumnya tidak ada. Meskipun ada solusi teknis, seperti mengonfigurasi hook untuk mendeteksi dan keluar lebih awal selama rebase, ini menambah kompleksitas. Beberapa pengembang menghindari masalah ini sama sekali dengan menggunakan perintah seperti git rebase -x hook untuk menjalankan pemeriksaan hanya ketika mereka menginginkannya, daripada memaksanya secara otomatis.
Alat Git Hook yang Umum Digunakan
- Pre-Commit: Sebuah framework mandiri untuk mengelola dan memelihara pre-commit hooks multi-bahasa. Framework ini memiliki fitur manajemen dependensi untuk hooks.
- Husky: Sebuah alat yang memerlukan Node.js dan npm, populer di ekosistem JavaScript untuk mengelola Git hooks.
- Prek: Sebuah re-implementasi berbasis Rust dari Pre-Commit yang masih dalam tahap pengembangan.
Mencari Keseimbangan yang Tepat
Terlepas dari kekurangannya, komunitas mengakui satu manfaat pre-commit hook yang hampir tidak disangkal: mencegah rahasia untuk di-commit. Alat seperti Gitleaks dapat memindai kunci API atau kata sandi yang tidak sengaja di-commit, dan menangkapnya secara lokal adalah kemenangan keamanan yang besar. Untuk alasan ini saja, banyak tim merasa biaya pemasangan hook dapat dibenarkan.
Kunci untuk adopsi hook yang sukses tampaknya adalah kurasi yang cermat. Tim didorong untuk hanya menyertakan pemeriksaan yang sangat cepat dan tidak mengganggu. Pemformat cepat dan pemindai rahasia adalah kandidat yang bagus. Linter yang lambat dan rangkaian pengujian penuh bukanlah kandidat yang baik. Tujuannya adalah untuk membantu pengembang tanpa menjadi penghalang. Seperti yang dikatakan seorang komentator dengan singkat, tujuannya adalah untuk menjaga putaran itu tetap ketat dan aktif.
Pada akhirnya, diskusi mengungkapkan bahwa tidak ada solusi yang cocok untuk semua. Keefektifan Git hook sangat bergantung pada ukuran proyek, alur kerja tim, dan kinerja alat yang mendasarinya. Meskipun mereka dapat menjadi bagian yang kuat dari strategi jaminan kualitas, mereka memerlukan implementasi yang bijaksana untuk menghindari menjadi sumber frustrasi yang justru dipelajari oleh pengembang untuk diakali daripada digunakan bersama.
Catatan: Rebase adalah operasi Git untuk menerapkan kembali serangkaian commit ke base commit baru, sering digunakan untuk membersihkan riwayat.
Referensi: Diskusi tentang Manfaat dan Kelemahan Git Pre-Commit Hook