Perintah Git yang Dijalankan Sebelum Membaca Kode

 (piechowski.io)
89 poin oleh GN⁺ 2026-04-09 | 1 komentar | Bagikan ke WhatsApp
  • Saat pertama kali menghadapi codebase baru, analisis riwayat Git untuk memahami struktur proyek dan area berisiko sehingga arah eksplorasi bisa ditetapkan dengan lebih efisien
  • Temukan file yang paling sering berubah dalam 1 tahun terakhir, lalu bandingkan frekuensi perubahan dengan konsentrasi bug untuk mengidentifikasi kode berisiko tinggi
  • Melalui distribusi kontributor dan tren aktivitas, periksa kemungkinan bus factor, celah pemeliharaan, dan putusnya pengetahuan
  • Lacak perubahan kecepatan dan momentum pengembangan tim lewat jumlah commit bulanan, dan nilai stabilitas rilis dari frekuensi Revert·Hotfix
  • Lima perintah ini dapat digunakan sebagai alat praktis untuk mendiagnosis kesehatan proyek dengan cepat sebelum membuka satu baris kode pun

Lima Perintah Git yang Dijalankan Sebelum Membaca Kode

  • Saat menganalisis codebase baru, ini adalah pendekatan untuk mendiagnosis kesehatan proyek melalui riwayat Git sebelum membuka file
    • Lewat riwayat commit, kita bisa memahami siapa yang membuatnya, di mana masalah terkonsentrasi, dan seberapa stabil tim melakukan rilis

  • Apa yang Paling Sering Berubah

    • Perintah: 
      git log --format=format: --name-only --since="1 year ago" | sort | uniq -c | sort -nr | head -20
    • Menampilkan 20 file teratas yang paling banyak dimodifikasi dalam 1 tahun terakhir
    • File-file teratas sering kali merupakan file yang “takut disentuh” tim; ketika frekuensi perubahan tinggi (churn) berpadu dengan penghindaran kepemilikan, file tersebut menjadi beban terbesar dalam codebase
    • Menurut riset Microsoft Research (2005), metrik berbasis frekuensi perubahan lebih baik dalam memprediksi cacat dibanding metrik kompleksitas
    • Bandingkan 5 file teratas ini dengan perintah konsentrasi bug untuk mengidentifikasi file yang sering berubah sekaligus sering bermasalah sebagai elemen berisiko terbesar

  • Siapa yang Membangun Kode Ini

    • Perintah: 
      git shortlog -sn --no-merges
      Iklan
    • Memberi peringkat kontributor berdasarkan jumlah commit
    • Jika satu orang menyumbang lebih dari 60%, ada risiko bus factor
    • Jika kontributor utama tidak aktif dalam 6 bulan terakhir, ada kemungkinan celah pemeliharaan
    • Jika dari 30 kontributor hanya 3 yang aktif dalam 1 tahun terakhir, bisa terjadi putusnya pengetahuan akibat pergantian developer
    • Namun, tim yang memakai strategi squash-merge dapat mengalami distorsi informasi penulis karena berpusat pada pihak yang melakukan merge, sehingga strategi merge perlu diperiksa

  • Di Mana Bug Terkonsentrasi

    • Perintah: 
      git log -i -E --grep="fix|bug|broken" --name-only --format='' | sort | uniq -c | sort -nr | head -20
    • Mengekstrak 20 file teratas yang terkait bug berdasarkan commit yang memuat kata kunci terkait bug
    • Bandingkan daftar ini dengan daftar frekuensi perubahan untuk mengidentifikasi file yang sering diperbaiki dan sering rusak sebagai kode berisiko tinggi
    • Akurasi hasil memang bergantung pada kualitas pesan commit, tetapi tetap sangat berguna bahkan sebagai peta kasar kepadatan bug

  • Apakah Proyek Sedang Melaju atau Mandek

    • Perintah: 
      git log --format='%ad' --date=format:'%Y-%m' | sort | uniq -c
      Iklan
    • Melalui jumlah commit per bulan, kita bisa melihat tren aktivitas secara visual
    • Ritme yang konsisten menandakan proyek yang sehat
    • Jika jumlah commit turun setengah hanya dalam satu bulan, ada kemungkinan personel inti keluar
    • Penurunan berkelanjutan selama 6~12 bulan menunjukkan melemahnya momentum tim, sedangkan lonjakan berkala yang diikuti stagnasi mengisyaratkan pola rilis berbasis batch
    • Ada kasus nyata di mana melalui grafik kecepatan commit, seorang CTO menyadari, “itulah saat engineer senior pergi”
    • Data ini bermakna sebagai data tim, bukan data kode

  • Seberapa Sering Tim Sedang Menangani Keadaan Darurat

    • Perintah: 
      git log --oneline --since="1 year ago" | grep -iE 'revert|hotfix|emergency|rollback'
    • Mengukur frekuensi Revert·Hotfix
    • Beberapa kejadian per tahun masih normal, tetapi jika muncul setiap dua minggu, itu sinyal ketidakpercayaan terhadap proses rilis
    • Ini merupakan tanda dari masalah yang lebih dalam seperti tes yang tidak stabil, tidak adanya staging, atau prosedur rollback yang rumit
    • Jika hasilnya 0, bisa berarti tim memang stabil atau pesan commit tidak akurat
    • Pola krisis terlihat dengan jelas, dan keberadaannya saja sudah cukup untuk menilai tingkat kepercayaan

Kesimpulan

  • Lima perintah ini bisa dijalankan hanya dalam beberapa menit, dan sebelum membuka satu baris kode pun sudah memberi arah dari mana harus mulai membaca
  • Dengan ini, hari pertama tidak dihabiskan untuk menjelajah secara acak, melainkan memungkinkan analisis kode yang sistematis dengan fokus pada area bermasalah
  • Prosedur ini setara dengan satu jam pertama dalam audit codebase (codebase audit), lalu berlanjut ke proses analisis selama seminggu berikutnya

Bacaan terkait

1 komentar

 
GN⁺ 2026-04-09
Opini Hacker News

  • Membagikan contoh di Jujutsu yang bisa menggantikan perintah analisis git
    File yang paling sering berubah dalam 1 tahun terakhir, kontributor utama, lokasi tempat bug terkonsentrasi, vitalitas proyek, frekuensi perbaikan darurat, dan lain-lain bisa dicek dengan perintah jj log
    Sintaksnya lebih mirip pemrograman daripada skrip shell, tetapi jumlah flag yang harus diingat lebih sedikit

    • Bagiku jujutsu terlihat seperti Nix untuk sistem kontrol versi
      Seperti Nix yang keren tetapi menambah kompleksitas, jujutsu juga terasa seperti itu
      Setelah memakainya beberapa bulan, aku kembali ke git. git sudah terbiasa di tangan dan bisa dipakai di mana saja
    • Aku tidak paham bagaimana orang bisa menghafal semua bahasa skrip kustom seperti ini
      Bisa mengingat loop array di jq saja sudah menyenangkan, jadi sintaks seperti ini benar-benar sulit kupahami
    • Perintah jj maupun git sama-sama terlalu panjang dan rumit untuk dihafal
      Kalau sering dipakai, aku akan mempersingkatnya dengan alias
    • Tidak adanya commit bukan berarti proyek itu mati, justru bisa berarti stabil
      Misalnya ada library pembuat kode QR yang sudah 10 tahun tidak diperbarui, tetapi bekerja dengan sempurna
      Kadang jadi berpikir apakah perlu menambahkan commit tak berguna dengan bot hanya untuk formalitas
    • Aku tidak ingin memprogram git, aku cuma ingin menyelesaikan pekerjaan
      Karena itu aku lebih suka perintah pipe UNIX tradisional daripada alat seperti jujutsu
      Alasanku memakai Maven alih-alih Gradle juga sama

  • Menarik bahwa penulis berasumsi para developer menulis pesan commit dengan baik
    Kenyataannya, kebanyakan cuma setingkat “changed stuff”
    Orang seperti aku yang menganggap log commit penting itu minoritas
    Pesan commit yang dihasilkan AI bisa sangat membantu masalah seperti ini

    • Ini adalah masalah kepemimpinan. Team lead atau CTO yang baik akan menetapkan ekspektasi yang jelas soal kualitas pesan commit
    • Di tim yang merge dengan squash PR, isi PR menjadi pesan commit, jadi kualitasnya cenderung lebih baik
    • Dalam workflow squash & merge, pada akhirnya judul PR menjadi pesan inti
      Developer bebas menulis pesan commit sesukanya, karena toh nanti tidak dibaca
    • Tim kami membedakan repo Core dan repo Non-Core
      Untuk Core, review PR dan penjelasan detail wajib ada, sedangkan di Non-Core orang bebas bereksperimen
      Di Core, pesan commit kadang 20 kali lebih panjang daripada kodenya, sedangkan di Non-Core levelnya cuma “hope this works”
    • Developer tidak menulis pesan commit dengan baik adalah masalah budaya
      Di perusahaan kami, kami saling menuntut hal itu

  • Aku menjalankan perintah-perintah itu pada beberapa codebase, dan hasilnya berbeda dari kondisi nyata
    Misalnya, dalam hasil git shortlog -sn --no-merges, orang dengan commit terbanyak ternyata sudah keluar dari perusahaan
    Banyaknya commit tidak berarti kontribusinya paling besar

    • Karena itu aku lebih suka squash-and-merge
      Commit yang terlalu banyak dibiarkan hanya di feature branch, lalu ke main di-merge dengan rapi
    • Perintah seperti ini berguna saat mendiagnosis proyek yang bermasalah
      Pada codebase biasa, hasilnya sering tidak terlalu berarti
    • Sejujurnya aku ragu penulis benar-benar menjalankan perintahnya, terasa seperti tulisan LLM
    • Jika workflow otomatis menggunakan kredensial satu orang, statistiknya bisa terdistorsi
    • Aku juga punya jumlah commit yang sangat dominan di codebase pusat sebuah perusahaan
      Itu karena aku yang membuat proyeknya dari awal, dan sekarang orang lain lebih sering melakukan commit

  • Ucapan bahwa “file yang paling sering berubah adalah file yang orang takut sentuh” terasa menarik

    • Mirip paradoks seperti “restoran yang terlalu ramai sampai tidak ada yang pergi ke sana”
    • Setelah diuji, file yang paling sering diubah ternyata file hasil generate otomatis atau file membosankan seperti entry point
    • Perintah seperti ini perlu peringatan
      Kalau langsung menarik kesimpulan dari hasil eksekusinya, justru bisa terlihat bodoh
      Pada praktiknya ini hanya menunjukkan fitur apa yang dikerjakan selama setahun terakhir
    • Jika melihat Churn (frekuensi perubahan) bersama Complexity (kompleksitas), hasilnya jauh lebih berguna
      Area yang tinggi di keduanya itulah zona masalah yang sebenarnya
      Kalau area seperti ini menumpuk, muncullah ucapan “aplikasi ini harus ditulis ulang dari awal”
    • File yang ditakuti orang adalah file yang esensial sekaligus kompleks
      Semua orang harus mengubahnya, tetapi terlalu besar dan sulit ditangani

  • Aku membuat alias summary di git untuk sekaligus menampilkan ringkasan branch, jumlah commit, jumlah penulis, jumlah file, dan sebagainya
    Idenya didapat dari GitAlias/gitalias

    • Aku penasaran kenapa itu ditulis sebagai fungsi .gitconfig, karena rasanya lebih sederhana kalau dibuat saja sebagai skrip git-summary
    • Mengetik perintah seperti ini satu per satu setiap saat terasa seperti tulisan AI, pengguna berpengalaman biasanya membuat alias untuk dipakai ulang
    • Skripnya keren, tetapi di lingkunganku tidak ada perintah seperti log-of-count-and-email
    • Sepertinya bagus juga kalau membuat halaman man secara lokal

  • Harus menambahkan batas kata (\b) ke regex
    Misalnya hasil bisa salah karena kata “bug” yang ada di dalam “debugger”
    Contoh yang sudah diperbaiki seperti berikut
    git log -i -E --grep="\b(fix|fixed|fixes|bug|broken)\b" ...

    • Di macOS, \b tidak didukung, jadi alih-alih -E harus memakai opsi regex Perl -P
      Bisa diubah menjadi bentuk git log -i -P --grep="\b(...)\b"
    • Kami juga memakai kata “rollback” dengan makna lain, jadi perlu difilter
    • Masukan yang bagus, jadi jauh lebih akurat

  • Jika tidak melakukan squash-merge, orang dengan jumlah commit terbanyak justru bisa jadi developer yang paling berantakan
    Dulu ada orang seperti itu; dia terus-menerus mengubah file yang sama lalu akhirnya dipecat
    Squash adalah cara yang bagus untuk menyamarkan masalah seperti ini

  • Statistik jumlah commit yang sederhana sulit dipercaya
    Ada orang yang hanya commit kode yang sudah teruji sempurna, ada juga yang commit satu baris demi satu baris
    Nilai satu commit bisa berbeda 100 kali lipat antarorang

    • Tetapi tujuan penulis adalah melihat tren perubahan
      Laju perubahan lebih bermakna daripada nilai absolut

  • Pendekatan analisis seperti ini mengingatkanku pada “Your Code as a Crime Scene” karya Adam Tornhill
    Tautan asli
    Juga mirip dengan konsep Developer’s Legacy Index

    • Aku suka tulisan-tulisan awal Tornhill tentang C, jadi senang melihatnya lagi

  • Akan lebih bagus kalau penulis langsung menampilkan hasil dari tiap perintah
    Contoh output akan lebih meyakinkan daripada penjelasan

    • Aku juga merasa tulisannya agak terasa seperti ditulis AI, tetapi tetap tidak buruk karena aku jadi belajar lima perintah