Hampir semua kebingungan pemula soal Git hilang begitu kamu paham bahwa perubahan berpindah melewati empat "ruangan":

Analogi gampangnya: kamu mau kirim paket. Working directory itu meja kerjamu, tempat barang berserakan. Staging area itu kardus, tempat kamu memilih barang mana yang ikut dikirim. Commit itu menyegel kardus dan memberi label. Push itu mengirim kardus ke gudang pusat (remote).

Kenapa perlu staging, tidak langsung commit saja? Karena kamu sering mengubah banyak file sekaligus, padahal idealnya satu commit berisi satu perubahan logis. Dengan staging, kamu bisa memilih: commit perbaikan bug dulu, lalu fitur baru di commit terpisah.

Ada juga arah sebaliknya:

• git restore <file>: membuang perubahan di working directory, kembali ke versi terakhir.
• git restore --staged <file>: mengeluarkan file dari staging area (cara lama: git reset HEAD <file>).
• git fetch / git pull: mengambil commit terbaru dari remote.

Dari sudut pandang Git, setiap file di working directory punya status:

• Untracked: file baru yang belum pernah dikenal Git.
• Modified: file yang sudah dilacak, isinya berubah, tapi belum di-stage.
• Staged: perubahan sudah masuk staging area, siap ikut commit berikutnya.
• Committed (unmodified): isi file sama dengan versi di commit terakhir.

git status adalah kompasmu. Versi singkatnya, git status -s, memakai dua kolom kode: kolom kiri untuk staging, kolom kanan untuk working directory.

Kode MM menarik: staging menyimpan isi file saat kamu menjalankan git add. Kalau setelah itu kamu mengedit lagi, edit terbaru belum ikut, jadi kamu perlu git add sekali lagi.

Di dalam folder .git/objects, Git menyimpan tiga jenis objek utama:

• Blob: isi sebuah file, hanya kontennya, tanpa nama file.
• Tree: struktur direktori, berisi daftar nama file beserta blob-nya (dan tree lain untuk subfolder).
• Commit: menunjuk ke satu tree (potret proyek), plus penulis, waktu, pesan, dan commit induk.

Ada juga tag, penanda permanen ke sebuah commit yang biasanya dipakai untuk rilis.

Setiap objek diberi nama berupa hash SHA-1 sepanjang 40 karakter heksadesimal yang dihitung dari isinya. Isi sama, hash pasti sama. Isi beda satu byte saja, hash berubah total. Inilah sumber integritas data Git. Biasanya kamu cukup melihat 7 karakter awalnya, seperti di git log --oneline.

VCS lama menyimpan daftar perubahan (diff) per file: versi 2 = versi 1 + perubahan. Git berpikir lain. Setiap commit adalah snapshot utuh seluruh proyek. File yang tidak berubah tidak disalin ulang, melainkan cukup ditautkan ke blob yang sama. Karena itu Git bisa langsung melompat ke commit mana pun tanpa harus "memutar ulang" semua perubahan dari awal.

Folder .git di akar proyek adalah repositorimu yang sebenarnya. Isinya antara lain HEAD (penunjuk branch aktif), config (konfigurasi local), index (staging area), objects/ (semua blob, tree, commit), dan refs/ (branch serta tag). Hapus .git, dan seluruh riwayat ikut hilang, sementara file proyekmu tetap ada sebagai folder biasa.

Buat repositori latihan dan amati statusnya berubah:

mkdir latihan-git && cd latihan-git
git init
echo "# Halo Git" > README.md
git status -s

?? README.md

git add README.md
git status -s
git commit -m "Tambah README"

A  README.md
[main (root-commit) 348e2d6] Tambah README
 1 file changed, 1 insertion(+)
 create mode 100644 README.md

Hash commitmu pasti berbeda, karena bergantung pada nama, email, dan waktu. Sekarang intip objeknya:

git cat-file -p HEAD

tree 7aed22714180b9b54db8ef7d3bfbdd5fb81baabb
author Rani Putri <rani@contoh.com> 1792586550 +0700
committer Rani Putri <rani@contoh.com> 1792586550 +0700

Tambah README

git cat-file -p 7aed227

100644 blob c79f97b548aa7452add2b3d9938286850db8693e	README.md

Hash tree dan blob ini akan sama persis di laptopmu, karena hanya bergantung pada isi. Buktikan juga snapshot berbagi blob:

cp README.md salinan.md
git add salinan.md
git commit -m "Tambah salinan"
git cat-file -p HEAD^{tree}

100644 blob c79f97b548aa7452add2b3d9938286850db8693e	README.md
100644 blob c79f97b548aa7452add2b3d9938286850db8693e	salinan.md

Dua nama file, satu blob. Terakhir, ubah file lalu cek kodenya:

echo "baris dua" >> README.md
git status -s

 M README.md

• Mengira git add sudah menyimpan ke riwayat. add hanya memasukkan ke staging. Riwayat baru tercatat setelah git commit.
• Mengira commit langsung sampai ke GitHub. Commit tersimpan di local repository. Perlu git push untuk mengirimnya ke remote.
• Mengedit lagi setelah git add lalu langsung commit. Edit terakhir tertinggal, terlihat sebagai MM di git status -s.
• Menghapus atau mengedit isi .git secara manual. Biarkan Git yang mengurus folder itu.