git log, diff, show, dan blame: cara membaca riwayat proyek di Git

Empat perintah ini menjawab hampir semua pertanyaan tentang riwayat proyek. git log menjawab «apa yang terjadi», git diff menjawab «apa yang sebenarnya berubah», git show menjawab «apa isi commit tertentu», dan git blame menjawab «siapa yang menulis baris ini dan kapan». Berikut ini teknik praktis untuk masing-masing, dengan flag yang benar-benar dipakai dalam pekerjaan harian.

git log: daftar commit

Tanpa argumen, git log menampilkan commit pada branch aktif dari yang terbaru ke yang terlama: hash SHA-1 lengkap, penulis, tanggal, dan pesan. Keluarannya ditampilkan di pager (biasanya less): spasi untuk halaman berikutnya, /teks untuk mencari, dan q untuk keluar.

commit 7be41d0c9a2e4f1b8d6c3e5a7f9b0c2d4e6f8a1b
Author: Anna Petrova <anna@example.com>
Date:   Mon Oct 5 14:22:10 2026 +0300

    feat: cache untuk respons API

Hash tidak perlu disalin utuh. Git memahami awalan unik mulai dari 4 karakter, dan dalam praktik 7 karakter sudah cukup.

Keluaran ringkas: --oneline

git log --oneline -10
# 7be41d0 (HEAD -> main, origin/main) feat: cache untuk respons API
# 1c02e8f fix: timeout permintaan
# 9a4b3c2 refactor: pindahkan klien ke modul tersendiri

Flag -10 (atau -n 10) membatasi jumlah commit. Di dalam tanda kurung ada penunjuk: di mana HEAD, cabang lokal dan remote, serta tag.

Graf cabang: git log --graph

Permintaan «git graph» biasanya merujuk pada hal ini: visualisasi percabangan dan penggabungan langsung di terminal.

git log --oneline --graph --all
# * 3e1f0aa (feature/auth) feat: login dengan token
# | * 7be41d0 (HEAD -> main) feat: cache untuk respons API
# |/
# * 1c02e8f fix: timeout permintaan
# *   5d2c7b1 Merge branch 'feature/search'
# |\
# | * 8f3a9e0 feat: pencarian
# |/
# * 9a4b3c2 refactor: pindahkan klien ke modul tersendiri

--all menampilkan semua branch, bukan hanya branch aktif. Akan praktis jika Anda membuat alias: git config --global alias.lg "log --oneline --graph --all --decorate", lalu cukup ketik git lg.

Format sendiri: --pretty=format

git log --pretty=format:"%h %ad %an %s" --date=short
# 7be41d0 2026-10-05 Anna Petrova feat: cache untuk respons API

Placeholder utama: %h — hash pendek, %H — hash lengkap, %an — nama penulis, %ae — e-mail penulis, %ad — tanggal penulis, %ar — tanggal relatif («2 days ago»), %s — judul pesan.

Cara memfilter riwayat di git log

Berdasarkan penulis dan tanggal

git log --author="Anna"
git log --since="2 weeks ago" --until="2026-10-01"
git log --since=yesterday --oneline

--author menerima ekspresi reguler dan mencari berdasarkan nama maupun e-mail. Git memahami tanggal dalam bahasa sehari-hari maupun format ISO.

Berdasarkan teks pesan

git log --grep="fix" -i --oneline

-i membuat pencarian tidak membedakan huruf besar-kecil. Jika tim Anda menulis nomor tugas di pesan commit, cara ini dengan cepat menemukan semua commit untuk satu tugas.

Berdasarkan berkas atau folder

git log --oneline -- src/api/client.py
git log --follow -p -- src/api/client.py

Tanda minus ganda memisahkan path dari nama branch. --follow melanjutkan riwayat sebuah berkas melewati penggantian nama (hanya untuk satu berkas), dan -p menampilkan patch untuk setiap commit.

Berdasarkan perubahan kode: mencari «kapan kode ini ditambah»

git log -S "retry_count" --oneline     # commit yang mengubah jumlah kemunculan string tersebut
git log -G "timeout\s*=" --oneline    # commit yang diff-nya memuat baris yang cocok dengan regex

-S menemukan commit tempat sebuah fungsi atau variabel ditambahkan atau dihapus. Ini sangat berguna saat Anda perlu memahami ke mana perginya suatu potongan kode.

Rentang commit

git log main..feature      # yang ada di feature tetapi tidak di main
git log origin/main..HEAD  # commit lokal saya yang belum dikirim
git log --no-merges        # tanpa commit merge
git log --stat             # berkas apa saja yang berubah dan berapa baris

git diff: apa yang sebenarnya berubah

Hal terpenting tentang git diff adalah memahami dua keadaan mana yang dibandingkan. Kebingungan di sini adalah penyebab pertanyaan «kenapa diff-nya kosong, padahal saya sudah mengubah semuanya».

Jika sudah menjalankan git add, git diff biasa akan kosong, karena perubahannya sudah berada di index; gunakan --staged. Berkas baru yang belum pernah ditambahkan sama sekali tidak ditampilkan oleh diff.

Cara membaca keluaran diff

diff --git a/config.py b/config.py
index 3b18e51..a1c4f02 100644
--- a/config.py
+++ b/config.py
@@ -10,7 +10,7 @@ DEFAULTS = {
     "host": "localhost",
-    "timeout": 5,
+    "timeout": 30,
     "retries": 3,

Baris dengan - dihapus, dengan + ditambahkan, dan sisanya adalah konteks. Header @@ -10,7 +10,7 @@ berarti potongan ini dimulai pada baris 10 dan memakan 7 baris di versi lama maupun versi baru.

Flag git diff yang berguna

git diff --stat main feature      # ringkasan per berkas
git diff --name-only HEAD~3       # hanya nama berkas yang berubah
git diff --word-diff               # perubahan per kata, nyaman untuk teks
git diff -w                        # abaikan perubahan spasi
git diff main feature -- src/      # batasi ke satu folder

Sebelum setiap commit, biasakan melihat git diff --staged. Ini kesempatan terakhir untuk menangkap print debug yang tertinggal atau berkas yang tidak sengaja ikut.

git show: satu commit secara utuh

git show menampilkan metadata commit beserta diff terhadap induknya. Tanpa argumen, yang ditampilkan adalah commit terakhir.

git show 7be41d0
git show HEAD~2 --stat           # tanpa patch, hanya ringkasan
git show v1.2.0                  # tag: anotasi dan commit-nya
git show main:src/config.py      # isi berkas seperti yang ada pada commit

Bentuk terakhir <revisi>:<path> sangat berguna: Anda bisa melihat versi lama sebuah berkas tanpa berpindah ke commit itu. Arahkan keluarannya ke berkas, dan isi yang terhapus bisa dipulihkan tanpa checkout.

git blame: siapa yang mengubah baris ini

git blame berkas menampilkan, untuk setiap baris, commit terakhir yang mengubahnya, penulisnya, dan tanggalnya. Namanya terdengar menuduh, tetapi sebenarnya ini alat untuk mencari konteks: temukan commit-nya, baca pesannya, dan pahami mengapa kode ditulis begitu.

git blame -L 40,60 src/api/client.py
# 1c02e8f3 (Anna Petrova 2026-09-28 11:04:51 +0300 41)     timeout = settings.timeout
# 9a4b3c2e (Ivan Smirnov 2026-09-14 18:30:02 +0300 42)     session = build_session()

• -L 40,60 — hanya rentang baris; bisa juga -L :nama_fungsi.
• -w — abaikan perubahan spasi agar tidak jatuh pada commit pemformatan.
• -C — lacak baris yang dipindahkan dari berkas lain.
• --ignore-rev <hash> atau berkas .git-blame-ignore-revs — lewati commit massal seperti pemformatan otomatis.

Pola penyelidikan yang umum: git blame menemukan commit, git show menampilkannya secara utuh, dan git log pada berkas itu memperlihatkan perubahan lain di sekitarnya.

Bernavigasi ke masa lalu: HEAD~ dan HEAD^

Commit bisa dirujuk tidak hanya dengan hash. HEAD~1 adalah induk dari commit saat ini, HEAD~3 adalah kakek buyut. HEAD^2 adalah induk kedua dari commit merge. Nama branch, tag, dan branch remote juga bisa dipakai: origin/main~2. Untuk melihat seluruh proyek pada commit lama, gunakan git switch --detach <hash>, dan untuk kembali gunakan git switch -.

Riwayat yang baik dan yang buruk

Semua perintah ini hanya berguna sejauh riwayatnya bermakna. Pesan seperti «fix», «wip», atau «revisi lagi» membuat git log --grep dan git blame tidak ada gunanya. Commit yang baik adalah satu perubahan logis dengan judul yang menjelaskan apa dan mengapa: fix: naikkan timeout API ke 30 detik karena gateway lambat. Enam bulan kemudian, commit seperti inilah yang ditemukan blame dan menghemat satu jam kerja Anda.

Praktik: menyelidiki bug lewat riwayat

Misalnya, setelah rilis terbaru permintaan ke API mulai gagal karena timeout. Begini rangkaian perintah yang menuntun ke penyebabnya dalam beberapa menit.

1. Lihat apa yang masuk ke rilis: git log v1.4.0..v1.5.0 --oneline. Daftarnya pendek, tetapi dari judulnya pelakunya belum jelas.
2. Persempit ke berkas: git log v1.4.0..v1.5.0 --oneline -- src/api/. Tersisa dua commit.
3. Cari di kode: git log -S "timeout" --oneline -- src/api/ menemukan commit yang mengubah nilai timeout.
4. Lihat commit itu secara utuh: git show 1c02e8f. Dari diff terlihat bahwa timeout diturunkan dari 30 menjadi 5 detik, dan pesannya menjelaskan «mempercepat respons UI».
5. Periksa siapa lagi yang menyentuh baris ini: git blame -L :build_session src/api/client.py.

Setelah itu keputusannya ada di tangan insinyur: mengembalikan nilainya, memindahkan timeout ke pengaturan, atau membatalkan commit dengan git revert. Jika commit-nya ratusan dan tidak mungkin ditelusuri dengan mata, git bisect bisa dipakai: pencarian biner pada riwayat yang dalam beberapa langkah menunjuk commit yang merusak perilaku.

Pengaturan yang memudahkan

git config --global log.date iso            # format tanggal di log
git config --global diff.colorMoved zebra   # sorot baris yang dipindahkan di diff
git config --global core.pager "less -FRX"  # tidak membuka pager untuk keluaran pendek

Jika keluaran akan diproses skrip, matikan warna dan pager: git --no-pager log --format="%H %s" --no-color. Untuk pemrosesan mesin, gunakan hash lengkap %H, karena awalan pendek bisa menjadi ambigu seiring bertambahnya commit di repositori besar.

Ringkasan

git log dengan filter --oneline, --graph, --author, -S, dan path menjawab pertanyaan «apa yang terjadi». git diff membandingkan folder kerja, index, dan commit; kuncinya adalah mengingat apa yang dibandingkan secara default. git show membuka satu commit atau versi lama sebuah berkas, dan git blame menuntun dari sebuah baris kode ke keputusan yang melahirkannya. Membaca riwayat dan bernavigasi di antara commit dibahas dengan praktik dalam kursus Git.