git stash: satu file saja, tanpa kehilangan sisanya

Sebuah code review datang ketika tiga file sedang setengah disunting dan hanya satu yang boleh bergerak. Menyimpan semuanya ke stash lalu mengetik ulus dua file lainnya adalah ritual yang tidak dirindukan siapa pun.

TL;DR: git stash push -m "alasan" -- <path> menyimpan ke stash tepat path yang disebutkan dan membiarkan sisa pohon kerja Anda yang kotor tetap tenang. Ambil kembali perubahan dengan git stash pop (atau keluarkan satu file dari stash mana pun dengan git restore --source stash@{0} -- <path>). Bentuk pathspec hadir di git 2.13, rilis Mei 2017 — semua toolchain delapan tahun terakhir memilikinya.

git stash push -m "app.conf prod tweak" -- app.conf
git stash list
# stash@{0}: On main: app.conf prod tweak
git stash pop

Stash file-nya, bukan pohonnya.

Bagaimana melakukan stash satu file di git?

git stash polos menyapu seluruh working tree — setiap modifikasi terlacak masuk ke stash dan semuanya kembali ke HEAD. Itu bentuk yang keliru ketika pohon kotor Anda campuran: satu file siap diserahkan, sisanya jujur saja belum selesai. Solusinya adalah kata kerja push dengan pathspec, sesuai dokumentasi git-stash:

# sebelum: tiga file kotor
$ git status --short
 M app.conf
 M notes.md
 M main.py

# stash hanya app.conf
$ git stash push -m "app.conf prod tweak" -- app.conf
Saved working directory and index state On main: app.conf prod tweak

$ git status --short
 M notes.md
 M main.py

app.conf kembali ke kondisi commit-nya dan masuk ke stash@{0}; notes.md dan main.py tidak pernah bergeser. Pesan -m opsional, tetapi setimpal dengan tiga detiknya begitu git stash list menampilkan lebih dari satu entri — stash bernama “WIP” menua dengan buruk.

Dua detail yang penting:

• Pathspec berada setelah --. Semua setelah tanda pisah ganda adalah path, bukan flag. Konvensi yang sama dengan git checkout -- <path> dan bukan hiasan: git stash push -- main.py dan git stash push main.py berbeda pada versi lama, ketika path telanjang bisa salah baca.
• File untracked butuh -u. File yang benar-benar baru tidak punya riwayat terlacak untuk disimpan, jadi push biasa melewatinya. git stash push -u -- newfile.py menyertainya; -a melangkah lebih jauh dan menyapu juga yang diabaikan.

Bagaimana menyimpan sebagian satu file saja?

Ketika file itu sendiri setengah jadi — tiga hunk bagus, satu memalukan — alur interaktif memotongnya:

git stash -p            # atau: git stash push -p

Git menyusuri tiap hunk dan bertanya Stash this hunk [y,n,q,a,d,j,g,/,e,p,?]?. Jawab y untuk hunk yang masuk stash, n untuk yang tinggal. Hasilnya sebuah stash hanya berisi yang Anda setujui, dan sisa file tetap kotor di pohon. Mekanika hunk demi hunk yang sama juga menjalankan git add -p, jadi refleksnya pindah pakai.

	git stash push -- <path>	git stash -p
Granularitas	seluruh file	hunk individual
Kecepatan	satu perintah, bisa di-skrip	interaktif, hunk demi hunk
Dapat diulang di CI	ya (path sebagai argumen)	tidak — butuh manusia di prompt
Terbaik untuk	“file ini, bukan sisanya”	“perubahan ini, bukan yang itu”
Sejak	git 2.13 (Mei 2017)	tersedia sejak lama

Panduan praktis dari model dokumentasinya sendiri: pathspec saat batasnya adalah file, -p saat batasnya di dalamnya.

Bagaimana mengambil kembali file hasil stash?

git stash pop memulihkan stash@{0} dan menghapus entrinya. Itu jalur normal — tetapi pop adalah semua-atau-tidak-sama-sekali per stash, dan konflik membatalkan pop dengan entri tetap ada. Dua opsi yang lebih halus:

# 1. terapkan tanpa menghapus (bisa diulang tanpa risiko)
git stash apply stash@{0}

# 2. keluarkan SATU file dari stash, entrinya tetap utuh
git restore --source stash@{0} -- app.conf
# ejaan sebelum 2.23 untuk operasi yang sama:
git checkout stash@{0} -- app.conf

Bentuk restore/checkout menjawab kasus “saya menyimpan tiga perubahan sekaligus dan sekarang hanya butuh satu” — menyalin isi stash path itu ke working tree dan membiarkan stash@{0} berdiri. Catatan: ini menimpa salinan working tree; jika suntingan saat ini pada path itu berarti, bandingkan dulu:

git diff stash@{0} -- app.conf

Stash disimpan sebagai commit sungguhan dalam tumpukan mirip reflog — itulah mengapa stash@{0} menerima sintaks commit-ish apa pun, dan mengapa stash yang terhapus keliru masih dapat dipulihkan dari reflog sampai garbage collection memakannya.

Kapan stash adalah alat yang salah?

Stash adalah coretan, bukan branch: tak bernama di git branch, tanpa review, tanpa diff yang tampil secara bawaan, dan entri yang menumpuk dalam diam hingga terlupa. Jika pekerjaan yang berjalan harus selamat dari pergantian konteks antar mesin atau hari, commit ke sebuah branch — riwayat yang menyertai lebih berharga daripada tumpukan tanpa nama. Saat commit yang diparkir itu harus mendarat di tempat lain, git cherry-pick mengangkutnya. Dan saat tujuannya membatalkan alih-alih memarkir, pohon keputusan di git undo last commit yang berlaku.

Buku catatan jujur mode kegagalan, semuanya dari perilaku terdokumentasi:

Gejala	Penyebab	Solusi
File hilang setelah stash	path untracked dilewati	git stash push -u -- <path>
error: Your local changes ... would be overwritten saat pop	path berubah sejak stash	commit atau stash kondisi baru, lalu pop
Perubahan yang di-pop lenyap	pop menabrak konflik dan batal	selesaikan, lalu git stash apply
“Stash yang mana tadi?”	tumpukan stash tanpa nama	pesan -m, selalu

Catatan rilis Mei 2017 yang menambahkan pathspec ke git stash push kini berusia delapan tahun, dan sebagian besar ingatan otot git stash lebih tua dari itu. Layak dipelajari ulang: sapuan seluruh pohon kini adalah kasus khusus, bukan bawaan.