git stash: isang file lang, hindi binabago ang iba

Darating ang code review habang kalahating-tapos ang tatlong file at isa lang ang pwedeng gumalaw. I-stash ang lahat at i-type ulit ang dalawa — ang ritwal na walang namimiss.

TL;DR: git stash push -m "bakit" -- <path> ay naka-stash lang sa mga path na binanggit at pinapanatag ang natitira ng dirty tree mo. Ibalik ang changes gamit ang git stash pop (o kunin ang isang file mula sa kahit anong stash gamit ang git restore --source stash@{0} -- <path>). Dumating ang pathspec na anyo sa git 2.13, inilabas noong Mayo 2017 — kahit anong toolchain ng nakaraang walong taon ay mayroon nito.

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

Ang file ang i-stash, hindi ang puno.

Paano mag-stash ng isang file lang sa git?

Ang hubad na git stash ay wawalis sa buong working tree — lahat ng tracked na pagbabago ay papasok sa stash at babalik lahat sa HEAD. Maling hugis iyon kapag halo-halo ang dirty tree: isang file ay handa nang iabot, ang natitira ay tapat na hindi pa tapos. Ang sagot ay ang pandiwa na push na may pathspec, ayon sa git-stash documentation:

# bago: tatlong dirty files
$ git status --short
 M app.conf
 M notes.md
 M main.py

# i-stash lang ang 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

Bumalik ang app.conf sa committed state at pumanhik sa stash@{0}; ang notes.md at main.py ay di gumalap-galap. Opsyonal ang -m na mensahe pero sulit ang tatlong segundo kapag may ikalawa na sa git stash list — mabilis matanda ang mga stash na pinangalanang “WIP”.

Dalawang detalyeng may bisa:

• Ang pathspec ay pagkatapos ng --. Lahat pagkatapos ng dobleng gitling ay path, hindi flag. Parehong konbensyon ng git checkout -- <path> at hindi pampalamuti: sa mas lumang bersyon, magkaiba ang git stash push -- main.py at git stash push main.py — maaaring mabasa nang mali ang hubad na path.
• Kailangan ng -u ang untracked files. Walang tracked history para i-stash ang bagong-tao na file, kaya nilalaktawan ito ng ordinaryong push. git stash push -u -- newfile.py ang sasama rito; mas malayo pa ang -a — kasa-samahan din ang mga ignored.

Paano mag-stash ng bahagi ng isang file lang?

Kapag mismong file ang kalahati — tatlong magagandang hunk, isang nakakahiya — pinuputol-putol ito ng interactive flow:

git stash -p            # o: git stash push -p

Ikikilos ng Git ang bawat hunk at magtatanong: Stash this hunk [y,n,q,a,d,j,g,/,e,p,?]?. Sagutan ng y ang hunk na papasok sa stash, n ang maiiwan. Ang resulta: stash na laman lang ang inaprubahan, at ang natitira ng file ay dirty pa rin sa puno. Parehong hunk-per-hunk na makinarya ang gumagana sa git add -p, kaya direktang lilipat ang reflex.

	git stash push -- <path>	git stash -p
Granularity	buong file	hiwalay na hunk
Bilis	isang command, scriptable	interactive, hunk-per-hunk
Uulitin sa CI	oo (path bilang argumento)	hindi — kailangan ng tao sa prompt
Pinakaangkop sa	“itong file, hindi ang iba”	“itong change, hindi iyon”
Mula noong	git 2.13 (Mayo 2017)	matagal nang available

praktikal na tuntunin mula sa modelo ng mismong docs: pathspec kung ang hangganan ay ang file, -p kung nasa loob ito.

Paano ibabalik ang naka-stash na file?

Ibinabalik ng git stash pop ang stash@{0} at binubura ang entry. Iyon ang normal na daan — pero all-or-nothing bawat stash ang pop, at kapag may conflict, humihinto ang pop habang nananatili ang entry. Dalawang mas pino na opsyon:

# 1. i-apply nang hindi binubura (ligtas ulitin)
git stash apply stash@{0}

# 2. Kunin ang ISANG file mula sa stash, mananatili ang entry
git restore --source stash@{0} -- app.conf
# mas lumang baybay ng parehong operasyon (bago ang 2.23):
git checkout stash@{0} -- app.conf

Ang anyong restore/checkout ang sumasagot sa sitwasyong “tatlong change ang naka-stash ko nang magkakasama, pero isa lang ang kailangan ko ngayon” — kinokopya nito ang naka-stash na nilalaman ng path na iyon sa working tree at pinapaiwan ang stash@{0}. Tandaan: binabura nito sa overwrite ang kopya sa working tree; kung mahalaga ang kasalukuyang edits sa path na iyon, mag-diff muna:

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

Ang mga stash ay iniimbak bilang tunay na commit sa isang stack na kamukha ng reflog — kaya tinatanggap ng stash@{0} ang kahit anong commit-ish syntax, at ang stash na nailagas nang hindi sinasadya ay nababawi pa mula sa reflog hangga’t hindi kinakain ng garbage collection.

Kailan mali ang stash bilang tool?

Ang stash ay scratchpad, hindi branch: walang pangalan sa git branch, walang review, walang default na ipinapakitang diff, at ang mga entry ay tahimik na nagtutumpak hanggang makalimutan. Kung ang work-in-progress ay dapat makaligtas sa pagbabago ng konteksto sa pagitan ng mga makina o araw, i-commit sa branch — mas mabuti ang nakalakip na history kaysa walang-pangalang stack. Kapag kailangan nang lumapag sa ibang lugar ang mga nai-park na commit na iyon, si git cherry-pick ang magsasakay. At kung layunin ay ibawi, hindi i-park, ang decision tree sa ibawi ang huling commit ang dapat sundin.

Ang tapat na aklat ng mga sira — lahat mula sa dokumentadong pag-uugali:

Sintomas	Sanhi	Lunas
Wala ang file pagkatapos ng stash	nilalaktawan ang untracked paths	git stash push -u -- <path>
error: Your local changes ... would be overwritten sa pop	nagbago ang path mula noong stash	i-commit o i-stash ang bagong state, saka mag-pop
Nawala ang mga nakuha na change	nabangga ng pop ang conflict at huminto	i-resolba, saka git stash apply
“Aling stash nga ba?”	tambak ng mga walang-pangalang stash	-m na mensahe, palagi

Walong taon na ang Mayo 2017 release note na nagdagdag ng pathspec sa git stash push, at mas matanda pa ang karamihan sa muscle memory ng git stash. Sulit na aralin muli: ang pagwawalis sa buong puno ngayon ang special case, hindi ang default.