Perintah Git yang Dijalankan Sebelum Membaca Kode

• 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
    

  • 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
    

  • 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