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:
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 statusOutput yang Dihasilkan:
[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:
git diffOutput yang Dihasilkan:
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:
git restore README.mdSama 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:
cat README.md
git statusOutput yang Dihasilkan:
# Situs Dokumentasi
Kumpulan catatan teknis tim.
On branch main
nothing to commit, working tree cleanBaris 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:
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 -sOutput yang Dihasilkan:
M README.md
M glosarium.mdDua 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:
cat README.md glosarium.mdOutput yang Dihasilkan:
# Situs Dokumentasi
Kumpulan catatan teknis tim.
## Glosarium
- commit: catatan satu keadaan proyekBentuk 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
:
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 -sOutput yang Dihasilkan:
MM README.md
M README.mdSebelum 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:
cat README.mdOutput yang Dihasilkan:
# 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:
git restore --source=HEAD --staged --worktree README.mdOpsi --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:
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.mdPerintah 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:
# 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:
| Perintah | Area yang ditimpa | Sumber salinan | Nasib suntingan working tree |
|---|---|---|---|
git restore README.md | working tree | index | dibuang permanen |
git restore --staged README.md | staging area (index) | HEAD | tetap utuh |
git checkout -- README.md | working tree | index | dibuang 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 .