Tiga Area Git: diff vs --staged vs HEAD

Tiga area yang harus kamu hafal

Git menyimpan pekerjaanmu di tiga tempat berbeda, dan kebingungan diff hampir selalu berasal dari tidak tahu Git sedang membandingkan area mana dengan mana:

1. Working tree: file di folder kerjamu, yang kamu edit langsung.
2. Index (staging area): hasil git add, yaitu "paket" yang siap di-commit.
3. HEAD: commit terakhir di branch aktif, titik acuan yang sudah permanen.

Kenapa tiga area ini ada? Supaya kamu bisa menyusun commit dengan presisi: edit banyak file, tapi hanya commit sebagian. Tanpa staging area, setiap commit akan menyeret semua perubahan sekaligus.

git diff: working tree vs index

git diff

Perintah polos ini membandingkan working tree dengan index. Artinya: ia hanya menampilkan perubahan yang BELUM di-git add. Contoh skenario: kamu edit app.js, lalu git add app.js, lalu edit lagi. Maka git diff hanya menampilkan editan kedua, karena editan pertama sudah "naik" ke index.

Kapan dipakai? Tepat sebelum git add, untuk memeriksa "apa yang akan aku staging". Ini kebiasaan review diri sendiri yang mencegah file nyasar masuk commit.

git diff --staged: index vs HEAD

git diff --staged

Ini membandingkan index dengan HEAD. Artinya: ia menampilkan persis apa yang AKAN masuk ke commit berikutnya kalau kamu mengetik git commit sekarang. (Alias lamanya --cached, fungsinya sama.)

Kapan dipakai? Tepat sebelum git commit, sebagai pemeriksaan terakhir. Kalau ada baris debug atau console.log yang tidak sengaja ke-add, di sinilah kamu menangkapnya. Developer berpengalaman hampir tidak pernah commit tanpa melihat git diff --staged dulu.

git diff HEAD: working tree vs HEAD

git diff HEAD

Ini membandingkan working tree langsung dengan HEAD, melewatkan index. Artinya: ia menampilkan SEMUA perubahan yang belum di-commit, baik yang sudah di-staging maupun belum. Kapan dipakai? Saat kamu ingin gambaran total "seberapa jauh aku menyimpang dari commit terakhir", misalnya sebelum memutuskan untuk stash atau reset.

Contoh gabungan dalam satu sesi kerja:

git diff --stat        # ringkasan perubahan belum di-staging
git add -p             # staging per potongan baris
git diff --staged      # verifikasi isi commit
git commit -m "Perbaiki validasi"
git diff HEAD --stat   # seharusnya kosong, semua sudah aman

Tabel cepat tiga perintah

Kesalahan umum pemula

Salah: setelah git add semua file, menjalankan git diff lalu panik karena "kok kosong, padahal aku baru edit banyak". Benar: git diff polos memang tidak menampilkan yang sudah di-staging. Lihat hasilnya dengan git diff --staged.

Salah: commit tanpa pernah mengecek diff, lalu commit berisi file .env atau console.log yang tidak sengaja ke-add. Benar: jadikan git diff --staged sebagai ritual wajib sebelum git commit. Lima detik melihat diff bisa menghemat satu jam memperbaiki commit yang salah.