Staging Area

Pada tahap ini pola kerjanya sudah jelas: sunting berkas di working tree, lalu catat ke riwayat. Namun commit yang baik sering kali harus lebih kecil daripada total suntingan kita — satu fitur selesai sementara fitur lain masih setengah jadi, dan keduanya tidak layak dicampur dalam satu pesan commit. Git menjawab kebutuhan ini dengan staging area: keranjang persiapan tempat kita memilih perubahan mana yang akan menjadi commit berikutnya. Chapter ini mendalami konsep keranjang tersebut, membuktikan cara kerjanya dengan demo dua berkas yang hanya satu dipilih, lalu menimbang kapan jalan pintas -a layak dipakai.

Keranjang untuk Commit Berikutnya #

Staging area adalah daftar keadaan berkas yang akan membentuk snapshot commit berikutnya. Daftar ini tersimpan sebagai berkas fisik bernama index di dalam .git — itulah sebabnya dokumentasi Git juga menyebutnya index, dan beberapa opsi lama menyebutnya cached. Tiga nama itu merujuk pada benda yang sama: staging area, index, dan cache adalah satu.

Perintah git add <berkas> melakukan satu hal presisi: menyalin keadaan berkas saat perintah dijalankan ke dalam index. Bukan sekadar “menandai berkas sebagai siap” — yang tersimpan adalah isi berkas pada momen itu. Perintah git commit tanpa tambahan apa pun kemudian memotret seluruh isi index sebagai snapshot baru. Commit berikutnya, dengan demikian, adalah hasil kurasi kita, bukan hasil foto seluruh folder sekenanya.

Demo: Memilih Sebagian Suntingan #

Mari kita buktikan. Mulai dari working tree yang bersih pada latihan sebelumnya, sunting dua berkas tracked sekaligus — README.md dan glosarium.md — lalu pilih hanya salah satunya:

printf '# Situs Dokumentasi\n\nKumpulan catatan teknis tim.\nBerkas ini dikelola bersama seluruh anggota tim.\n' > README.md
printf '## Glosarium\n\n- commit: catatan satu keadaan proyek\n- staging area: keranjang perubahan terpilih\n- repository: wadah riwayat beserta berkasnya\n' > glosarium.md
git add glosarium.md
git status

Output yang Dihasilkan:

On branch main
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
	modified:   glosarium.md

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	modified:   README.md

Keluaran tersebut terbelah menjadi dua bagian, dan pembelahnya adalah staging area:

1. Changes to be committed — isi keranjang saat ini: suntingan glosarium.md yang barusan kita pilih dengan git add. Bagian inilah yang akan menjadi commit berikutnya.
2. Changes not staged for commit — suntingan README.md yang masih tertinggal di working tree. Git melihat perubahannya, tetapi perubahan itu belum masuk keranjang dan tidak akan ikut commit berikutnya.

Bila kita menjalankan git commit -m "Tambah istilah repository pada glosarium" saat ini, commit hanya memuat suntingan glosarium.md; suntingan README.md tetap menunggu di working tree sebagai bagian kerja yang belum selesai. Petunjuk (use "git restore --staged <file>..." to unstage) pada bagian pertama menunjukkan cara membatalkan pilihan — topik yang dibedah pada chapter Membatalkan Staging .

Mengapa Tidak Commit Semua Sekaligus #

Pembaca yang berasal dari alat lain mungkin bertanya: mengapa repot-repot memilih? Jawabannya terletak pada kualitas riwayat. Tabel berikut membandingkan kedua kebiasaan itu:

Kebiasaan men-stage juga memberi satu momen periksa sebelum menulis: baris Changes to be committed memperlihatkan daftar berkas yang akan masuk, sehingga kejutan seperti berkas rahasia atau berkas sisa uji coba tertangkap sebelum ikut tercatat permanen. Prinsip “satu commit satu maksud” ini yang akan kita pakai terus sampai materi proyek terapan.

Jalan Pintas -a #

Git menyediakan bentuk ringkas untuk kebiasaan “memang niat mencatat semuanya”: opsi -a pada git commit memasukkan semua suntingan berkas tracked ke staging area sebelum commit dibuat.

git commit -am "Perbarui pengantar dan glosarium"

Opsi -a menggantikan git add untuk berkas tracked yang berubah — perintah di atas setara dengan git add kedua berkas lalu git commit -m. Dua batasannya penting untuk diingat: berkas untracked tetap harus di-git add manual karena belum dikenal Git, dan sifat pilihannya hilang — semua suntingan berkas tracked ikut masuk. Opsi lengkap beserta bentuk-bentuk lain dari git commit dibahas pada chapter git commit .

Staging area kini jelas perannya: ruang transit berisi kurasi kita, tersimpan sebagai berkas index di dalam .git. Satu pertanyaan terakhir belum terjawab: seperti apa bentuk database yang menerima kiriman dari ruang transit itu? Saatnya membedah isi .git sampai ke objeknya. Lanjut ke Git Directory .