Membatalkan Staging

Staging area adalah ruang kurasi, dan setiap ruang kurasi pasti pernah menerima item yang salah: berkas di-git add padahal pekerjaannya belum selesai, atau suntingan yang ternyata bukan bagian dari topik commit yang sedang disusun. Kabar baiknya, keanggotaan staging area tidak mengunci apa pun — berkas dapat dikeluarkan kapan saja tanpa kehilangan suntingan sedikit pun. Perintah modernnya adalah git restore --staged, hadir sejak Git 2.23 dan kini disarankan langsung oleh keluaran git status; bentuk warisannya, git reset HEAD, masih penting dikenali karena bersliweran di banyak dokumentasi lama. Chapter ini menjalankan keduanya, membuktikan bahwa suntingan tetap utuh di working tree setelah staging dibatalkan, lalu menegaskan satu perbedaan tanda baca yang berakibat fatal bila tertukar.

Mengeluarkan Berkas dari Staging Area #

Kita siapkan repository latihan dengan satu commit, lalu menyunting README.md dan mengangkatnya ke keranjang:

mkdir latihan-unstage && cd latihan-unstage
git init -b main
git config user.name "Budi Santoso"
git config user.email "[email protected]"
printf '# Situs Dokumentasi\n\nKumpulan catatan teknis tim.\n' > README.md
printf '## Glosarium\n\n- commit: catatan satu keadaan proyek\n' > glosarium.md
git add README.md glosarium.md
git commit -m "Commit awal situs dokumentasi"
printf '# Situs Dokumentasi\n\nKumpulan catatan teknis tim.\nKini dilengkapi panduan kontributor singkat.\n' > README.md
git add README.md
git status

Output yang Dihasilkan:

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

Baris modified: README.md di bawah Changes to be committed menandakan README.md sudah masuk keranjang. Petunjuk di atasnya bahkan menyebutkan perintah yang tepat — Git sendiri menyarankan git restore --staged <file> untuk mengeluarkannya:

git restore --staged README.md

Perintah tersebut berhasil tanpa mencetak apa pun — git restore --staged memang bekerja dalam senyap saat tidak ada masalah. Opsi --staged mengarahkan git restore untuk menyentuh staging area: entri index untuk README.md dikembalikan ke versi HEAD, sehingga berkas keluar dari calon commit berikutnya. Keadaannya dapat diperiksa kembali:

git status

Output yang Dihasilkan:

On branch main
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

no changes added to commit (use "git add" and/or "git commit -a")

README.md pindah ke daftar Changes not staged for commit — keadaan yang sama seperti sebelum git add dijalankan. Perilaku opsi ini terdokumentasi lengkap pada dokumentasi git restore .

Suntingan Tetap Aman di Working Tree #

Hal terpenting dari pembatalan staging: satu-satunya yang berubah adalah isi keranjang. Berkas di working tree tidak disentuh sama sekali, sehingga suntingan yang barusan kita buat tetap utuh:

cat README.md

Output yang Dihasilkan:

# Situs Dokumentasi

Kumpulan catatan teknis tim.
Kini dilengkapi panduan kontributor singkat.

Baris Kini dilengkapi panduan kontributor singkat. masih di tempatnya, dan git diff masih melaporkannya sebagai perubahan working tree:

git diff

Output yang Dihasilkan:

diff --git a/README.md b/README.md
index 5d6c796..820e03c 100644
--- a/README.md
+++ b/README.md
@@ -1,3 +1,4 @@
 # Situs Dokumentasi
 
 Kumpulan catatan teknis tim.
+Kini dilengkapi panduan kontributor singkat.

Bentuk Warisan: git reset HEAD #

Sebelum git restore ada, tugas yang sama dijalankan git reset HEAD <berkas>. Angkat ulang README.md ke keranjang, lalu keluarkan dengan bentuk warisan:

git add README.md
git reset HEAD README.md

Output yang Dihasilkan:

Unstaged changes after reset:
M	README.md

Berbeda dengan git restore --staged, git reset dengan pathspec melaporkan hasilnya: baris Unstaged changes after reset: diikuti daftar berkas yang keluar dari keranjang — kode M berarti berkas tersebut berstatus modified di working tree. Keadaan akhirnya identik dengan pembatalan lewat restore --staged:

git status

Output yang Dihasilkan:

On branch main
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

no changes added to commit (use "git add" and/or "git commit -a")

Kedua perintah menyetel index ke versi HEAD untuk berkas yang disebut, tanpa menyentuh working tree. Keduanya juga sama-sama bisa dipakai untuk beberapa berkas sekaligus. Wujud reset yang tanpa pathspec — yang menggerakkan posisi branch — adalah hewan yang sama sekali berbeda dan dibahas pada chapter git reset ; dokumentasi teknisnya ada di dokumentasi git reset .

Kasus Berkas Baru: Kembali Menjadi Untracked #

Perilaku yang menarik terjadi pada berkas baru yang belum pernah di-commit. Katakanlah kita membuat draf dan tidak sengaja mengangkatnya ke keranjang:

printf 'Draf catatan internal, belum siap dibagikan.\n' > catatan-pribadi.txt
git add catatan-pribadi.txt
git status

Output yang Dihasilkan:

On branch main
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
	new file:   catatan-pribadi.txt

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

catatan-pribadi.txt tampil sebagai new file di keranjang. Batalkan stagingnya:

git restore --staged catatan-pribadi.txt
git status

Output yang Dihasilkan:

On branch main
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

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	catatan-pribadi.txt

no changes added to commit (use "git add" and/or "git commit -a")

Karena berkas ini tidak punya versi di HEAD, index yang dikembalikan menjadi kosong — catatan-pribadi.txt kembali berstatus untracked, persis keadaan sebelum perintah git add pertama. Berkas fisiknya tetap utuh di disk dengan isi yang sama; tidak ada yang terhapus.

Jangan Tertukar dengan git restore tanpa –staged #

Dua perintah berikut hanya berbeda satu opsi, tetapi menulis dua akhir cerita yang berbeda:

Aturan praktisnya satu kalimat: --staged mengubah isi keranjang, tanpa --staged mengubah isi berkas. Dengan pembatalan staging ini, seluruh peralatan kurasi staging area lengkap — memilih per berkas, memilih per potongan, dan membatalkan pilihan. Sisanya adalah sisi cermin dari staging: bagaimana membuang suntingan yang memang tidak ingin disimpan sama sekali. Lanjut ke Membuang Perubahan Lokal .