Belajar Git - Membandingkan Perubahan & Inspeksi Kode

#Pendahuluan

Di episode 4 kalian mulai membangun riwayat commit yang rapi. Seiring bertambahnya riwayat, muncul pertanyaan krusial: apa sebenarnya yang berubah di commit ini? Apakah staging area sesuai harapan? Siapa yang menulis baris kode bermasalah ini?

Episode ini adalah pelatihan investigasi. Tiga perintah — git diff, git show, dan git blame — adalah alat detektif yang akan kalian pakai hampir setiap hari, baik saat code review, debugging, maupun mencari tahu kenapa sebuah baris kode ada.

#Membandingkan Perbedaan dengan git diff

#git diff: Working Directory vs Staging Area

git diff tanpa argumen membandingkan working directory dengan staging area — menampilkan perubahan yang belum di-stage.

Melihat perubahan yang belum di-stage

git diff
diff --git a/index.html b/index.html
--- a/index.html
+++ b/index.html
@@ -1 +1 @@
-<h1>Halo Dunia</h1>
+<h1>Halo, Git!</h1>

Cara membaca output diff:

Baris --- adalah versi lama, baris +++ adalah versi baru.
Baris bertanda - artinya dihapus, bertanda + artinya ditambahkan.

#git diff --staged: Staging Area vs Commit Terakhir

Untuk melihat perubahan yang sudah di-stage, gunakan git diff --staged (sinonim: --cached):

Melihat perubahan yang sudah di-stage

git diff --staged
git diff --cached

Sedangkan git diff HEAD membandingkan keduanya sekaligus: seluruh perbedaan antara working tree dan commit terakhir — gabungan perubahan staged dan unstaged.

#Membandingkan Dua Commit

Untuk melihat perbedaan antar dua commit sembarang, berikan dua hash:

Membandingkan dua commit

git diff 9c4a2d6e b8e1f3a7

Perintah ini menampilkan semua perubahan dari commit pertama menuju commit kedua — sangat berguna saat code review untuk melihat apa yang berubah dalam satu pull request.

#Peta Perbandingan Variasi git diff

Agar tidak bingung, ringkasan berikut mengurutkan perbandingan dari yang paling "segar" hingga yang paling historis:

Perintah	Membandingkan
`git diff`	Working directory vs staging area
`git diff --staged`	Staging area vs commit terakhir
`git diff HEAD`	Working tree vs commit terakhir (gabungan)
`git diff <c1> <c2>`	Dua commit secara langsung

Tip

Biasakan memeriksa git diff sebelum commit. Ini seperti memeriksa pekerjaan sebelum dikumpulkan — mencegah file build atau rahasia yang tidak sengaja ikut ter-stage. Sementara git diff --staged adalah pemeriksaan terakhir sebelum snapshot dikunci menjadi commit.

#Inspeksi Detail Commit dengan git show

git show <hash> menampilkan satu commit secara lengkap: metadata (penulis, tanggal, pesan) plus diff perubahan yang dibawanya. Ini jendela tercepat untuk memahami isi sebuah commit.

Membuka detail satu commit

git show b8e1f3a7
commit b8e1f3a7
Author: Arman Dwi Pangestu
    feat: tambah halaman login

git show HEAD menunjukkan commit terakhir; git show HEAD~1 menunjukkan satu commit sebelum HEAD. Tanpa argumen hash, git show menampilkan commit yang sedang aktif (HEAD).

#Mengidentifikasi Penulis dengan git blame

git blame <file> menjawab pertanyaan: siapa yang mengubah baris ini, kapan, dan pada commit mana?

Menelusuri penulis setiap baris

git blame login.js
b8e1f3a7 (Arman Dwi Pangestu 2026-08-01 10:22) function login(user) {
b8e1f3a7 (Arman Dwi Pangestu 2026-08-01 10:22)   if (!user.password) {
7a2c9d1e (Rina Sari 2026-07-28 14:05)   throw new Error("password wajib");

Setiap baris ditandai hash commit, penulis, tanggal, dan isi baris. Gunakan git blame saat menemukan bug: telusuri commit yang memperkenalkan baris bermasalah, lalu lihat konteks perubahan saat itu — sering kali alasannya jadi jelas.

Note

git blame memetakan baris pada commit terakhir yang menyentuhnya — bukan "menyalahkan" seseorang, melainkan melacak asal-usul kode. Berpikirlah konstruktif: ini alat untuk memahami, bukan menghakimi.

#Kapan Menggunakan yang Mana

Ketiga perintah ini saling melengkapi untuk skenario berbeda:

Sebelum commit — git diff untuk memeriksa perubahan mentah, lalu git diff --staged untuk memastikan staging area bersih dari yang tidak diinginkan.
Saat code review — git diff <c1> <c2> untuk melihat apa yang berubah di seluruh pull request; git show <hash> untuk menilai satu commit secara mendalam.
Saat debugging — git blame <file> menemukan commit pengenalan bug, lalu git show <hash> membuka konteks perubahan lengkap pada commit itu.

Important

Kombinasi git blame lalu git show adalah alur investigasi paling ampuh di Git: dari satu baris kode bermasalah, kalian bisa menelusuri seluruh riwayat hingga akar penyebabnya. Latih alur ini sampai terbiasa.

#Penutup

Rekap episode 5:

git diff membandingkan working directory vs staging area; git diff --staged untuk perubahan yang sudah di-stage.
git diff HEAD menggabungkan keduanya; git diff <commit1> <commit2> membandingkan dua commit.
git show <hash> membuka detail lengkap satu commit.
git blame <file> melacak penulis dan asal setiap baris kode.

Di episode 6 kita masuk babak baru yang paling dinanti: branching — memahami bahwa branch hanyalah pointer ringan, membuat dan berpindah branch dengan git switch, hingga menghapus dan mengubah nama branch. Dengan itu kalian siap mengerjakan fitur tanpa mengganggu pekerjaan utama. Sampai jumpa!