Pembatalan staging pada chapter sebelumnya menyelamatkan suntingan dari keranjang, tetapi suntingan itu tetap tinggal di working tree. Kadang keputusan kita justru sebaliknya: suntingan memang tidak ingin disimpan — percobaan yang gagal, penggantian sementara yang sudah selesai, atau suntingan pada berkas yang keliru. Untuk keadaan seperti itu, git restore <berkas> tanpa opsi --staged adalah perintah yang tepat: berkas di working tree ditimpa kembali dengan versi terakhir yang tercatat. Perintah ini bekerja senyap dan seketika, dan justru karena itu konsekuensinya perlu dipahami sejak awal: suntingan yang dibuang tidak bisa dipanggil kembali.

Membuang Suntingan di Working Tree #

Kita siapkan repository latihan dengan satu commit, lalu menyunting README.md dengan sebuah baris percobaan:

bash
mkdir latihan-buang && cd latihan-buang
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.\nSEMENTARA: pembaruan mingguan sedang disusun.\n' > README.md
git status

Output yang Dihasilkan:

text
[main (root-commit) 2a982e8] Commit awal situs dokumentasi
 2 files changed, 6 insertions(+)
 create mode 100644 README.md
 create mode 100644 glosarium.md
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")

Hash 2a982e8 dihitung dari isi commit, jadi nilainya berbeda di komputer pembaca. Petunjuk baris ketiga sudah menyebut perintah yang akan kita pakai — (use "git restore <file>..." to discard changes in working directory) memang merujuk ke tindakan membuang suntingan. Sebelum menjalankannya, biasakan melihat dulu apa yang akan hilang:

bash
git diff

Output yang Dihasilkan:

text
diff --git a/README.md b/README.md
index 5d6c796..908068f 100644
--- a/README.md
+++ b/README.md
@@ -1,3 +1,4 @@
 # Situs Dokumentasi
 
 Kumpulan catatan teknis tim.
+SEMENTARA: pembaruan mingguan sedang disusun.

Hanya satu baris tambahan — baris percobaan yang memang tidak ingin disimpan. Sekarang buang seluruh perubahan tersebut:

bash
git restore README.md

Sama seperti git restore --staged, perintah ini berhasil tanpa mencetak apa pun saat tidak ada masalah. Bukti bahwa berkas benar-benar kembali dapat dilihat dari isinya:

bash
cat README.md
git status

Output yang Dihasilkan:

text
# Situs Dokumentasi

Kumpulan catatan teknis tim.
On branch main
nothing to commit, working tree clean

Baris SEMENTARA: sudah tidak ada, dan git status melaporkan working tree bersih — satu-satunya versi README.md yang tersisa adalah versi commit terakhir.

Membuang Banyak Berkas Sekaligus #

Bekerja dengan beberapa berkas berantakan sekaligus tidak memerlukan perintah berulang. Pathspec dapat menerima banyak berkas, atau satu . untuk seluruh direktori kerja:

bash
printf '# Situs Dokumentasi\n\nKumpulan catatan teknis tim.\nDraf pengantar baru sedang diuji.\n' > README.md
printf '## Glosarium\n\n- commit: catatan satu keadaan proyek\n- repository: wadah riwayat beserta berkasnya\n' > glosarium.md
git status -s
git restore .
git status -s

Output yang Dihasilkan:

text
 M README.md
 M glosarium.md

Dua baris pertama adalah keluaran git status -s sebelum pembuangan: kedua berkas berstatus modified. Perintah git restore . berjalan senyap, dan git status -s kedua tidak mencetak apa pun — tidak ada lagi perubahan working tree di direktori ini. Isi kedua berkas kembali identik dengan versi commit terakhir:

bash
cat README.md glosarium.md

Output yang Dihasilkan:

text
# Situs Dokumentasi

Kumpulan catatan teknis tim.
## Glosarium

- commit: catatan satu keadaan proyek

Bentuk dua berkas eksplisit — git restore README.md glosarium.md — memberi kontrol yang sama untuk daftar berkas tertentu. Perlu dicatat bahwa . dan pathspec lain hanya menyentuh berkas yang Git kenal: suntingan pada berkas untracked tetap diabaikan, karena tidak ada versi tercatat yang bisa dipakai untuk menimpanya.

Sumber Default adalah Index, Bukan HEAD #

Ada satu nuansa yang baru terlihat ketika keranjang tidak kosong. git restore <berkas> menyalin dari staging area — bukan langsung dari commit terakhir. Kita buktikan dengan keadaan MM dari chapter Memahami Working Tree :

bash
printf '# Situs Dokumentasi\n\nKumpulan catatan teknis tim.\nDraf pengantar baru sedang diuji.\n' > README.md
git add README.md
printf '# Situs Dokumentasi\n\nKumpulan catatan teknis tim.\nDraf pengantar baru sedang diuji.\nEksperimen kedua yang belum masuk keranjang.\n' > README.md
git status -s
git restore README.md
git status -s

Output yang Dihasilkan:

text
MM README.md
M  README.md

Sebelum pembuangan, README.md memuat dua lapis perubahan: suntingan pertama sudah di-git add, suntingan kedua belum. Setelah git restore README.md, kode status berubah menjadi M — hanya suntingan kedua yang dibuang:

bash
cat README.md

Output yang Dihasilkan:

text
# Situs Dokumentasi

Kumpulan catatan teknis tim.
Draf pengantar baru sedang diuji.

Baris Draf pengantar baru sedang diuji. tetap ada karena versi itu tercatat di index — dan index-lah sumber salinan default git restore. Suntingan kedua hilang permanen karena tidak pernah tersimpan di mana pun. Untuk menyapu bersih kedua lapisan sekaligus, tiga opsi dapat dipadukan:

bash
git restore --source=HEAD --staged --worktree README.md

Opsi --source=HEAD menetapkan HEAD sebagai sumber salinan, --staged mengarahkan penimpaan ke index, dan --worktree mengarahkan penimpaan ke working tree. Kombinasi ketiganya mengembalikan README.md pada kedua area ke kondisi commit terakhir — git status -s kembali tidak mencetak apa pun. Peran opsi --source untuk menjangkau titik riwayat lain dibahas tuntas pada chapter Memulihkan File .

Bentuk Warisan: git checkout – #

Sebelum Git 2.23 memperkenalkan git restore, tugas yang sama dijalankan oleh git checkout -- <berkas>. Bentuk ini masih sering dijumpai di dokumentasi lama:

bash
printf '# Situs Dokumentasi\n\nKumpulan catatan teknis tim.\nDraf buangan untuk uji checkout.\n' > README.md
git checkout -- README.md
git status -s
cat README.md

Perintah git checkout -- README.md berjalan senyap dan git status -s tidak mencetak apa pun — README.md kembali ke versi index, hasil yang identik dengan git restore README.md:

Output yang Dihasilkan:

text
# Situs Dokumentasi

Kumpulan catatan teknis tim.

git checkout adalah perintah serba bisa warisan: selain menimpa berkas, perintah yang sama juga berperan mengganti branch dan membuat branch baru. Pemisahan tugas menjadi git restore untuk berkas dan git switch untuk branch hadir justru untuk mengurangi risiko checkout menjalankan hal yang tidak dimaksudkan. Membaca git checkout -- cukup untuk memahami dokumentasi lama, namun menuliskannya pada skrip baru tidak lagi dianjurkan — dokumentasi git restore mencatat git restore sebagai pengganti resminya.

Tiga Perintah yang Sering Tertukar #

Satu opsi boleh berbeda, hasilnya dua dunia. Tabel ini merangkum tiga bentuk yang kita temui sepanjang dua chapter terakhir:

PerintahArea yang ditimpaSumber salinanNasib suntingan working tree
git restore README.mdworking treeindexdibuang permanen
git restore --staged README.mdstaging area (index)HEADtetap utuh
git checkout -- README.mdworking treeindexdibuang permanen (warisan)

Membuang perubahan lokal selalu bergerak ke belakang menuju versi terakhir yang tercatat. Pertanyaan berikutnya: bagaimana jika versi yang kita butuhkan bukan versi terakhir, melainkan versi yang jauh lebih tua di riwayat? Lanjut ke Memulihkan File .