Tiga Area Kerja Git: Working, Staging, Repository

Alur yang selalu sama

Setiap perubahan file di Git melewati tiga area, berurutan, tanpa kecuali:

1. Working directory: folder proyek tempat kamu mengedit file seperti biasa. Git mengawasi tapi belum mencatat apa pun. Ini "meja kerja"-mu.
2. Staging area (index): "ruang tunggu". File yang masuk sini berarti "siap disimpan di commit berikutnya". Ini "nampan" tempat kamu menyusun apa saja yang mau dibungkus.
3. Repository: database .git tempat commit tersimpan permanen beserta riwayatnya. Ini "lemari arsip" yang terkunci rapi.

Alurnya selalu: edit → git add (working ke staging) → git commit (staging ke repository). Hafalkan panah ini, karena 90% kebingungan pemula berasal dari tidak tahu perubahannya sedang ada di area mana.

Analoginya seperti memesan makanan: kamu pilih menu di meja (working directory), pelayan mencatat pesanan di nota (staging area), dapur memasak dan pesanan resmi tercatat (repository). Nota bisa diubah-ubah sebelum diserahkan ke dapur, tapi begitu masuk dapur, sudah resmi.

Kenapa ada staging area? Bukankah ribet?

Pertanyaan bagus, dan hampir semua pemula menanyakannya. Jawabannya: staging area memberi kamu kontrol presisi atas isi setiap commit.

Contoh nyata: kamu memperbaiki bug di app.js sekaligus merapikan komentar di file yang sama. Tanpa staging, keduanya tercampur dalam satu commit berpesan "fix bug dan rapiin komentar", riwayat jadi kotor. Dengan staging, kamu bisa git add -p untuk memilih potongan perubahan (hunk) satu per satu: bug fix masuk commit pertama, rapi-rapi komentar masuk commit kedua. Hasilnya dua commit yang bersih, gampang di-review, dan gampang di-revert satu per satu kalau ada masalah.

Tanpa staging area, Git akan seperti kamera yang motret otomatis tiap 5 detik: banyak foto, tapi tidak ada yang niat. Staging area membuat setiap commit jadi keputusan sadar.

Contoh nyata 1: melihat perubahan berpindah area

Mulai dari file yang sudah di-commit, lalu ubah isinya:

echo "versi 2" >> halo.txt
git status --short

 M halo.txt

Huruf M di kolom kanan artinya: berubah di working directory, belum di-staging. Sekarang pindahkan ke staging:

git add halo.txt
git status --short

M  halo.txt

Huruf M pindah ke kolom kiri: sudah di-staging, siap di-commit. Terakhir, bungkus jadi commit:

git commit -m "Update halo.txt ke versi 2"
git status --short

(nothing, empty output)

Output kosong artinya ketiga area sudah sinkron, tidak ada perubahan menggantung. Inilah siklus hidup satu perubahan dari lahir sampai tersimpan.

Contoh nyata 2: mengintip isi tiap area

Dua perintah ini adalah "kaca intip"-mu sebelum commit:

git diff            # working dir vs staging: yang BELUM di-add
git diff --staged   # staging vs commit terakhir: calon isi commit

Biasakan mengecek git diff --staged sebelum commit, seperti mengecek belanjaan sebelum bayar di kasir. Kalau ada yang nyasar masuk staging, kamu bisa mengeluarkannya dulu dengan git restore --staged <file>.

Membaca status file dalam tiga area

git status --short

 M index.html      # M di kanan = termodifikasi di working dir, belum di-staging
M  style.css       # M di kiri = sudah di-staging
MM app.js          # M di dua sisi = di-staging, lalu diubah lagi sesudahnya
?? baru.txt        # ?? = file baru, belum dikenal Git (untracked)

Dua kolom itu masing-masing mewakili staging (kiri) dan working directory (kanan). Kasus MM menarik: sebagian perubahan sudah di-staging, tapi kamu mengedit lagi setelahnya, jadi ada versi baru yang belum di-staging. Setelah paham tabel ini, git status tidak akan membingungkan lagi.

Catatan teknis: staging area sebenarnya hanyalah sebuah file bernama index di dalam folder .git. Ia berisi daftar file beserta hash-nya yang akan dibungkus jadi commit berikutnya. Sederhana, tapi powerful: seluruh konsep "commit parsial" dan "commit presisi" bertumpu pada satu file ini.

Kapan konsep ini penting?

Setiap kali commit-mu tercampur urusan yang tidak berkaitan ("fix bug + update README + hapus console.log" dalam satu commit), itu tanda kamu melewatkan staging area. Commit yang fokus ke satu tujuan jauh lebih mudah di-review, di-revert, dan di-bisect saat ada bug. Senior developer membedakan dirinya dari junior salah satunya di sini: commit mereka selalu rapi dan atomik.

Kesalahan umum pemula

Salah: git commit langsung tanpa git add dulu, lalu heran kenapa muncul nothing to commit, working tree clean padahal file jelas berubah. Benar: Ingat panahnya: commit hanya membungkus isi staging area. Kalau staging kosong, tidak ada yang bisa dibungkus. Jalankan git add dulu, baru commit.

Salah: git add . secara membabi buta, sampai file .env berisi password ikut ter-commit dan ter-push ke GitHub. Benar: Cek git status dulu sebelum git add .. Kalau ada file sensitif, buat file .gitignore (dibahas di bab 4) supaya tidak pernah ikut ter-add.

Salah: Mengira file yang sudah di-staging "aman" dan tidak bisa batal. Benar: Staging itu ruang tunggu, bukan brankas. git restore --staged <file> mengembalikannya ke working directory tanpa menghapus perubahanmu.

Salah: Mengedit file lagi setelah git add lalu langsung commit, mengira semua perubahan ikut. Benar: Yang ikut commit hanya versi yang di-staging (kasus MM di atas). Kalau edit lagi setelah add, jalankan git add sekali lagi sebelum commit, atau pakai git commit -a untuk file yang sudah ter-track.