1. 項(xiàng)目概述理解 Git Stash 的“后悔藥”機(jī)制在團(tuán)隊(duì)協(xié)作或者個(gè)人開(kāi)發(fā)中我們經(jīng)常會(huì)遇到這樣的場(chǎng)景你正在一個(gè)功能分支上熱火朝天地寫(xiě)代碼突然線上出現(xiàn)了一個(gè)緊急Bug需要立即修復(fù)。你手頭的工作只做了一半既不想提交一堆不完整的、甚至編譯都通不過(guò)的代碼又不想直接丟棄這些修改。這個(gè)時(shí)候git stash命令就成了你的救星。它就像一個(gè)臨時(shí)的“儲(chǔ)物柜”幫你把工作區(qū)和暫存區(qū)的改動(dòng)干凈利落地藏起來(lái)讓你能快速切換到一個(gè)干凈的狀態(tài)去處理其他任務(wù)。然而這個(gè)“藏起來(lái)”的操作本身就隱含了一個(gè)后續(xù)動(dòng)作——“取出來(lái)”。如何從 stash 里恢復(fù)內(nèi)容這個(gè)看似簡(jiǎn)單的操作實(shí)則包含了恢復(fù)到哪里、恢復(fù)什么、以及恢復(fù)后 stash 條目如何處理等一系列關(guān)鍵決策。很多開(kāi)發(fā)者尤其是剛接觸 Git 不久的朋友常常在這里踩坑比如誤刪了 stash 棧里的記錄或者恢復(fù)時(shí)發(fā)生了沖突不知如何處理又或者搞不清pop和apply的區(qū)別導(dǎo)致代碼狀態(tài)混亂。今天我們就來(lái)徹底拆解git stash的恢復(fù)機(jī)制。這不僅僅是記住幾個(gè)命令更是理解 Git 工作流中“暫存態(tài)”的管理哲學(xué)。我會(huì)結(jié)合自己多年在復(fù)雜項(xiàng)目中的使用經(jīng)驗(yàn)從最基礎(chǔ)的恢復(fù)操作講到 stash 棧的深度管理再到各種疑難雜癥的排查技巧。無(wú)論你是想找回剛剛不小心pop掉的修改還是需要從一周前的 stash 記錄中撈出某個(gè)關(guān)鍵函數(shù)這篇文章都能給你一份清晰的“尋寶圖”。2. 核心概念解析Stash 是什么它存了什么在動(dòng)手恢復(fù)之前我們必須先搞清楚我們恢復(fù)的“對(duì)象”到底是什么。很多人對(duì)git stash的理解停留在“暫存修改”這個(gè)說(shuō)法不夠精確容易導(dǎo)致后續(xù)操作失誤。2.1 Stash 條目的本質(zhì)當(dāng)你執(zhí)行g(shù)it stash或git stash push時(shí)Git 實(shí)際上創(chuàng)建了一個(gè)特殊的、懸空的提交對(duì)象。這個(gè)提交對(duì)象非常獨(dú)特它不屬于任何分支。這就是為什么你 stash 之后切換到任何分支都能應(yīng)用它。它記錄了兩種狀態(tài)工作目錄Working Directory的改動(dòng)即所有已跟蹤文件被修改但還未git add的內(nèi)容。暫存區(qū)Index / Staging Area的改動(dòng)即已經(jīng)通過(guò)git add添加到暫存區(qū)的內(nèi)容。它默認(rèn)不包含未跟蹤的文件。除非你顯式使用-u--include-untracked或-a--all選項(xiàng)。你可以把 stash 條目想象成一個(gè)快照這個(gè)快照同時(shí)捕捉了“準(zhǔn)備提交的舞臺(tái)暫存區(qū)”和“后臺(tái)排練區(qū)工作區(qū)”的某一刻狀態(tài)?；謴?fù) stash就是把這個(gè)快照重新應(yīng)用到當(dāng)前的工作環(huán)境中。2.2 Stash 棧后進(jìn)先出的“儲(chǔ)物柜”Git 的 stash 不是一個(gè)單一的存儲(chǔ)位置而是一個(gè)棧。每次你執(zhí)行g(shù)it stash不指定消息Git 都會(huì)創(chuàng)建一個(gè)新的 stash 條目并將其壓入棧頂。這個(gè)棧結(jié)構(gòu)是理解如何定位和恢復(fù)特定 stash 的關(guān)鍵。使用git stash list命令可以查看當(dāng)前的棧情況$ git stash list stash{0}: WIP on main: 549a234 Fix typo in header stash{1}: WIP on feature/login: 2b3c4d5 Add user auth logic stash{2}: On develop: temp experimentstash{0}棧頂最近一次 stash 的記錄。stash{1}上一次 stash 的記錄。stash{n}數(shù)字n越大代表 stash 的時(shí)間越早。每個(gè)條目都包含一個(gè)由 Git 自動(dòng)生成的哈希標(biāo)識(shí)符如stash{0}和一個(gè)可選的描述信息通過(guò)git stash save message或git stash push -m message添加?；謴?fù)操作的核心就是指定你要操作哪個(gè)stash{n}。注意這個(gè)棧是存儲(chǔ)在本地倉(cāng)庫(kù)的.git目錄中的它不會(huì)隨著git push推送到遠(yuǎn)程倉(cāng)庫(kù)。這意味著你的 stash 是純粹的本地備份換一臺(tái)電腦或者克隆新倉(cāng)庫(kù)是無(wú)法看到之前 stash 的內(nèi)容的。這也提醒我們不要把 stash 當(dāng)作長(zhǎng)期備份工具它更適合短期、臨性的上下文切換。3. 基礎(chǔ)恢復(fù)操作apply、pop與branch最常用的恢復(fù)命令有三個(gè)它們的行為有細(xì)微但重要的差別選錯(cuò)了可能會(huì)帶來(lái)麻煩。3.1git stash apply應(yīng)用但不刪除這是最“安全”的恢復(fù)方式。它的行為是將指定 stash 條目中的修改應(yīng)用到當(dāng)前工作目錄但該 stash 條目依然保留在棧中。命令格式# 恢復(fù)最新的 stash棧頂 git stash apply # 恢復(fù)指定的 stash例如 stash{2} git stash apply stash{2}操作流程與意圖定位 stash如果不指定參數(shù)默認(rèn)應(yīng)用stash{0}。如果指定stash{n}則應(yīng)用對(duì)應(yīng)的歷史記錄。應(yīng)用修改Git 會(huì)嘗試將 stash 中的修改作為一個(gè)補(bǔ)丁patch打到當(dāng)前的工作區(qū)和暫存區(qū)。它會(huì)盡力恢復(fù)文件內(nèi)容到 stash 時(shí)的狀態(tài)。狀態(tài)恢復(fù)它還會(huì)嘗試恢復(fù)你 stash 時(shí)的暫存狀態(tài)。即原來(lái)在暫存區(qū)已a(bǔ)dd的文件在apply后會(huì)自動(dòng)回到暫存區(qū)原來(lái)只在工作區(qū)的文件則保持在工作區(qū)修改的狀態(tài)。保留記錄操作完成后git stash list里原來(lái)的記錄還在。適用場(chǎng)景不確定性的恢復(fù)你想先看看 stash 的內(nèi)容是什么或者想將同一份修改應(yīng)用到多個(gè)分支上進(jìn)行測(cè)試。重復(fù)使用這份 stash 里的修改可能是一個(gè)通用的補(bǔ)丁你需要在不同上下文中多次應(yīng)用它。安全第一你不想立即刪除 stash 記錄以防應(yīng)用后出現(xiàn)問(wèn)題還可以回退。實(shí)操心得 我習(xí)慣在應(yīng)用一個(gè)幾周前的 stash 前先用apply。因?yàn)闀r(shí)間久了代碼庫(kù)可能已經(jīng)發(fā)生了很大變化直接pop掉萬(wàn)一沖突解決錯(cuò)了原記錄就沒(méi)了。先用apply解決完沖突測(cè)試通過(guò)后再手動(dòng)drop掉那個(gè)舊的 stash 條目。3.2git stash pop應(yīng)用并刪除這是最“高效”但也更“危險(xiǎn)”的恢復(fù)方式。它的行為是將指定 stash 條目中的修改應(yīng)用到當(dāng)前工作目錄然后立即將該 stash 條目從棧中刪除。命令格式# 彈出并應(yīng)用最新的 stash git stash pop # 彈出并應(yīng)用指定的 stash git stash pop stash{1}與apply的核心區(qū)別pop apply drop。在應(yīng)用修改成功后它會(huì)自動(dòng)執(zhí)行g(shù)it stash drop來(lái)刪除剛剛應(yīng)用的 stash 條目。如果應(yīng)用過(guò)程中發(fā)生沖突pop命令會(huì)中止并且不會(huì)刪除該 stash 條目。這一點(diǎn)是保護(hù)機(jī)制防止你在沖突沒(méi)解決的情況下丟失備份。適用場(chǎng)景標(biāo)準(zhǔn)工作流你 stash 了當(dāng)前修改切換到其他分支完成任務(wù)后切回原分支并希望恢復(fù)之前的工作。這是stash/pop最經(jīng)典的使用場(chǎng)景一氣呵成。清理 stash 棧你確定某個(gè) stash 記錄不再需要保留希望恢復(fù)的同時(shí)保持棧的整潔。踩過(guò)的坑 新手最容易犯的錯(cuò)誤是連續(xù)執(zhí)行g(shù)it stash和git stash pop但中間忘了切換分支。結(jié)果就是你在同一個(gè)分支上 stash 了修改又立刻 pop 回來(lái)看似什么都沒(méi)做但如果期間有其他人推送了代碼你 pop 時(shí)可能會(huì)遇到?jīng)_突。所以pop前一定要明確自己是否在正確的目標(biāo)分支上。3.3git stash branch branch_name基于 stash 創(chuàng)建新分支這是解決復(fù)雜恢復(fù)場(chǎng)景的“終極武器”。它的行為是以 stash 條目對(duì)應(yīng)的原始提交為基礎(chǔ)創(chuàng)建一個(gè)新的分支并將 stash 內(nèi)容應(yīng)用到該分支的工作區(qū)如果成功則刪除該 stash 條目。命令格式# 基于最新的 stash 創(chuàng)建分支 feature-new git stash branch feature-new # 基于指定的 stash 創(chuàng)建分支 git stash branch fix-typo stash{2}操作流程解析Git 會(huì)首先找到創(chuàng)建該 stash 時(shí)你所在的那個(gè)提交即git stash list輸出中WIP on main: 549a234里的549a234。以這個(gè)提交為起點(diǎn)創(chuàng)建一個(gè)名為branch_name的新分支并切換過(guò)去。在這個(gè)新分支上對(duì) stash 內(nèi)容執(zhí)行apply操作。如果apply成功無(wú)沖突或沖突已解決則自動(dòng)執(zhí)行drop刪除該 stash 條目。為什么這是強(qiáng)大的工具想象一下你在一周前的主分支上做了一些實(shí)驗(yàn)性的改動(dòng)然后 stash 了。現(xiàn)在主分支已經(jīng)向前推進(jìn)了上百個(gè)提交。此時(shí)如果你直接在現(xiàn)在的主分支上apply那個(gè) stash很可能會(huì)面臨大量的、難以解決的沖突。因?yàn)榇a基線已經(jīng)完全不同了。 而git stash branch直接從一周前的那個(gè)提交點(diǎn)拉出新分支此時(shí)應(yīng)用 stash代碼基線是完全匹配的所以幾乎不會(huì)沖突。你可以在一個(gè)獨(dú)立、干凈的分支上從容地處理你那部分舊代碼之后再來(lái)考慮如何將其合并到現(xiàn)在的主分支例如通過(guò)rebase或仔細(xì)的合并。適用場(chǎng)景長(zhǎng)期擱置的 stash stash 存放時(shí)間很久當(dāng)前分支已經(jīng)物是人非直接恢復(fù)沖突太多。開(kāi)啟新功能 臨時(shí)產(chǎn)生的靈感或?qū)嶒?yàn)代碼stash 后覺(jué)得值得發(fā)展成一個(gè)完整功能用此命令一鍵創(chuàng)建功能分支。規(guī)避復(fù)雜沖突 預(yù)感到直接應(yīng)用會(huì)有一堆沖突不如另起爐灶。4. 高級(jí)恢復(fù)與狀態(tài)管理掌握了基礎(chǔ)恢復(fù)我們來(lái)看看一些更復(fù)雜的場(chǎng)景和技巧這些能讓你對(duì) stash 的掌控力再上一個(gè)臺(tái)階。4.1 選擇性恢復(fù)--index與文件路徑有時(shí)你并不想恢復(fù)整個(gè) stash而只想要其中的一部分?；謴?fù)暫存狀態(tài) 前面提到apply默認(rèn)會(huì)嘗試恢復(fù)暫存狀態(tài)。但這個(gè)行為有時(shí)會(huì)失效尤其是在解決沖突后。如果你想強(qiáng)制確保暫存區(qū)狀態(tài)被恢復(fù)可以使用--index選項(xiàng)。git stash apply --index這個(gè)選項(xiàng)告訴 Git“請(qǐng)嚴(yán)格按照 stash 時(shí)的狀態(tài)把當(dāng)時(shí)在暫存區(qū)的文件現(xiàn)在還放回暫存區(qū)?！?這在處理復(fù)雜的、分階段提交的修改時(shí)非常有用?；謴?fù)特定文件 你可以只將 stash 中某個(gè)或某幾個(gè)文件的修改恢復(fù)到工作區(qū)。# 從最新的 stash 中恢復(fù) src/utils.js 文件 git checkout stash{0} -- src/utils.js # 從指定的 stash 中恢復(fù)多個(gè)文件 git checkout stash{2} -- src/componentA.js src/componentB.css這里用的不是stash apply而是git checkout。stash{n}在這里被當(dāng)作一個(gè)特殊的“提交”來(lái)對(duì)待。執(zhí)行這個(gè)命令后指定文件的內(nèi)容會(huì)被恢復(fù)到工作目錄但它不會(huì)恢復(fù)該文件在 stash 時(shí)的暫存狀態(tài)文件會(huì)處于工作區(qū)修改的狀態(tài)。這是一個(gè)非常精細(xì)的操作。4.2 查看與對(duì)比恢復(fù)前的“安檢”在恢復(fù)之前尤其是恢復(fù)一個(gè)不熟悉的 stash 前先看看里面有什么是絕對(duì)的好習(xí)慣。查看 stash 內(nèi)容概覽# 顯示最新 stash 的詳細(xì)diff git stash show -p # 顯示指定 stash 的詳細(xì)diff git stash show -p stash{1} # 顯示最新 stash 的簡(jiǎn)短統(tǒng)計(jì)哪些文件被修改 git stash show-p是--patch的縮寫(xiě)它會(huì)輸出一個(gè)完整的 diff 補(bǔ)丁讓你清晰地看到每一行代碼的增刪改。這比直接恢復(fù)要安全得多。對(duì)比 stash 與當(dāng)前工作區(qū) 如果你想看看 stash 里的修改和當(dāng)前工作區(qū)的代碼有什么區(qū)別可以將其作為一個(gè)分支來(lái)對(duì)比。# 將 stash 內(nèi)容視為一個(gè)臨時(shí)分支進(jìn)行對(duì)比 git diff stash{0}這行命令會(huì)顯示當(dāng)前工作區(qū)包括暫存區(qū)與指定的 stash 內(nèi)容之間的差異。這有助于你判斷恢復(fù)這個(gè) stash 是否會(huì)覆蓋你當(dāng)前有價(jià)值的修改。4.3 清理 stash 棧drop、clear與prunestash 棧是本地存儲(chǔ)長(zhǎng)期不清理可能會(huì)積累大量無(wú)用條目造成管理混亂。git stash drop stash{n} 刪除指定的 stash 條目。例如git stash drop stash{1}。這是一個(gè)危險(xiǎn)操作刪除后難以恢復(fù)除非用下一節(jié)講到的reflog。git stash clear清空整個(gè) stash 棧。所有stash{n}記錄都會(huì)被永久刪除。使用前務(wù)必三思最好先用git stash list確認(rèn)沒(méi)有需要的內(nèi)容。git stash prune 這是一個(gè)更安全的清理命令。它會(huì)刪除那些已經(jīng)無(wú)法通過(guò)任何分支或標(biāo)簽引用到達(dá)的 stash 條目。但通常我們手動(dòng)創(chuàng)建的 stash 都屬于這一類所以它的效果有時(shí)接近c(diǎn)lear需要配合特定選項(xiàng)使用日常較少直接用。個(gè)人管理習(xí)慣 我習(xí)慣給重要的 stash 添加描述信息git stash push -m “實(shí)驗(yàn)新的緩存策略”。每周或每完成一個(gè)功能模塊后我會(huì)運(yùn)行g(shù)it stash list進(jìn)行一次回顧將已經(jīng)處理完或過(guò)期的 stash 用drop手動(dòng)清理掉。保持 stash 棧的清爽能極大提高效率避免誤操作。5. 疑難雜癥與數(shù)據(jù)恢復(fù)即使再小心也難免會(huì)遇到問(wèn)題恢復(fù)錯(cuò)了、沖突解決爛了、或者不小心刪除了 stash。別慌Git 通常還留有后路。5.1 恢復(fù)沖突及其解決當(dāng)你apply或pop一個(gè) stash 時(shí)如果 stash 中的修改與當(dāng)前工作目錄的修改在同一行或同一區(qū)域有沖突Git 會(huì)報(bào)告沖突并中止操作。沖突表現(xiàn) 命令行會(huì)顯示類似CONFLICT (content): Merge conflict in file的信息。沖突的文件會(huì)被標(biāo)記文件內(nèi)容中會(huì)包含標(biāo)準(zhǔn)的沖突標(biāo)記。解決流程不要恐慌。Git 只是暫停了操作你的 stash 記錄如果是pop和工作區(qū)都還在。使用git status查看哪些文件處于“未合并”狀態(tài)。手動(dòng)編輯沖突文件解決沖突即保留你想要的部分刪除沖突標(biāo)記。解決完所有沖突后將文件添加到暫存區(qū)git add resolved_file。完成恢復(fù)操作如果你用的是git stash apply解決沖突并add后操作就完成了。你可以選擇是否刪除原 stash (git stash drop)。如果你用的是git stash pop在解決沖突并add后還需要執(zhí)行g(shù)it stash drop來(lái)手動(dòng)完成pop的后半部分。因?yàn)閜op在沖突時(shí)沒(méi)有自動(dòng)刪除 stash?？蛇x繼續(xù)提交此時(shí)工作區(qū)的狀態(tài)就是你解決沖突后的 stash 內(nèi)容。你可以選擇繼續(xù)修改或直接提交。重要提示在解決 stash 沖突時(shí)git mergetool可能不如解決合并沖突時(shí)那么好用。我更推薦直接打開(kāi) IDE 或文本編輯器手動(dòng)解決思路更清晰。5.2 找回誤刪的 Stash借助 Reflog這是最關(guān)鍵的救命技巧如果你不小心執(zhí)行了git stash drop或git stash clear是不是數(shù)據(jù)就永遠(yuǎn)丟失了在大多數(shù)情況下不是的Git 有一個(gè)強(qiáng)大的日志機(jī)制叫引用日志reflog。它記錄了本地倉(cāng)庫(kù)中所有分支、HEAD、甚至 stash 的引用變更歷史。stash 的棧本質(zhì)上是一個(gè)叫refs/stash的引用它的每一次變動(dòng)都會(huì)被 reflog 記錄?；謴?fù)步驟查看 stash 的 refloggit reflog show --all | grep stash # 或者更直接地查看 .git/logs/refs/stash 文件 # 但使用 reflog 命令更安全你會(huì)看到一串記錄每條記錄都有一個(gè)哈希值如a1b2c3d和操作描述。找到你想要恢復(fù)的那條 stash 記錄對(duì)應(yīng)的哈希值。描述里可能會(huì)包含你當(dāng)時(shí) stash 的部分提交信息或自定義消息。使用git stash apply或git stash branch通過(guò)哈希值恢復(fù)# 假設(shè)你找到的哈希是 a1b2c3d git stash apply a1b2c3d注意這里直接使用完整的提交哈希而不是stash{n}的格式。因?yàn)槟莻€(gè) stash 引用已經(jīng)被刪除了但提交對(duì)象在 Git 的垃圾回收gc之前依然存在。時(shí)間窗口 reflog 記錄是有保存期限的默認(rèn)90天并且 Git 的垃圾回收 (git gc) 會(huì)清理掉那些不被任何引用指向的“懸空”對(duì)象。所以誤刪后盡快執(zhí)行恢復(fù)操作成功率接近100%。如果過(guò)了幾周甚至幾個(gè)月數(shù)據(jù)可能就真的被清理掉了。5.3 處理“Nothing to restore”或“No stash found”有時(shí)你會(huì)遇到No stash found或類似的錯(cuò)誤。原因和排查點(diǎn)如下stash 棧確實(shí)是空的運(yùn)行g(shù)it stash list確認(rèn)。使用了錯(cuò)誤的引用比如你執(zhí)行了git stash pop stash{5}但棧里只有3條記錄。確保索引號(hào)正確。在錯(cuò)誤的倉(cāng)庫(kù)路徑確保你當(dāng)前所在的目錄是 Git 倉(cāng)庫(kù)的根目錄或子目錄。.git 目錄損壞極少數(shù)情況可以嘗試git fsck檢查倉(cāng)庫(kù)完整性。6. 實(shí)戰(zhàn)經(jīng)驗(yàn)與最佳實(shí)踐最后分享一些從大量實(shí)戰(zhàn)中總結(jié)出來(lái)的經(jīng)驗(yàn)這些技巧能讓你的git stash使用體驗(yàn)更加流暢和安全。6.1 給 Stash 打標(biāo)簽使用描述信息永遠(yuǎn)不要依賴默認(rèn)的WIP on ...消息。每次 stash 時(shí)強(qiáng)制自己使用-m參數(shù)添加描述。# 不好的做法 git stash # 好的做法 git stash push -m “重構(gòu)用戶服務(wù)層前的狀態(tài) - 2023-10-27” git stash push -m “實(shí)驗(yàn)性功能A未完成的表單驗(yàn)證邏輯”清晰的消息讓你在list時(shí)一目了然一周后也不會(huì)忘記這個(gè) stash 里到底是什么。6.2 明確包含/排除文件理解git stash的選項(xiàng)精準(zhǔn)控制存儲(chǔ)內(nèi)容git stash -u或git stash --include-untracked 額外保存未跟蹤的新文件。這是非常常用的選項(xiàng)因?yàn)樾聞?chuàng)建的文件經(jīng)常需要和修改一起暫存。git stash -a或git stash --all 保存所有文件包括未跟蹤的和被忽略的.gitignore中的。除非有特殊需求比如要 stash 一些臨時(shí)日志文件否則慎用。git stash --keep-index stash 時(shí)只保存工作區(qū)的修改而保留暫存區(qū)的內(nèi)容不變。這適用于你已精心準(zhǔn)備好一部分要提交的更改在暫存區(qū)只想把剩下的、雜亂的修改先藏起來(lái)?；謴?fù)時(shí)也要注意狀態(tài)。6.3 建立清晰的工作流將 stash 融入你的日常 Git 工作流功能開(kāi)發(fā)中接到緊急任務(wù) -git stash push -m “保存功能X進(jìn)度”- 切換分支修復(fù) Bug - 修復(fù)完成提交 - 切回功能分支 -git stash pop。代碼審查前本地有多個(gè)雜亂的調(diào)試提交 - 使用git reset回退到功能起點(diǎn) - 將所有改動(dòng)git stash -u- 重新整理代碼做出干凈的提交 - 如果發(fā)現(xiàn)漏了東西從 stash 中checkout單個(gè)文件。多環(huán)境測(cè)試在分支A上 stash 一套配置修改 - 切換到分支B -git stash apply應(yīng)用配置進(jìn)行測(cè)試 - 測(cè)試完畢git checkout -- .丟棄配置修改或手動(dòng)還原 - 切回分支Agit stash pop繼續(xù)工作。6.4 一個(gè)完整的恢復(fù)決策流程圖面對(duì)一個(gè) stash如何選擇恢復(fù)命令你可以參考這個(gè)簡(jiǎn)單的決策樹(shù)需要恢復(fù)的 stash 是否很舊且當(dāng)前分支變化很大 -是- 考慮使用git stash branch創(chuàng)建新分支。否 - 恢復(fù)后是否需要保留 stash 記錄以備后用 -是- 使用git stash apply。否 - 恢復(fù)后是否可以立即刪除此 stash 記錄 -是- 使用git stash pop。否即不確定- 默認(rèn)使用git stash apply這是最安全的起點(diǎn)。歸根結(jié)底git stash的恢復(fù)不是一個(gè)孤立的命令操作而是對(duì) Git 工作流中“臨時(shí)狀態(tài)”管理的深刻理解。從簡(jiǎn)單的pop到應(yīng)對(duì)沖突再到利用reflog絕地求生每一步都要求我們清楚自己在操作什么。把它當(dāng)成一個(gè)強(qiáng)大的、但需要謹(jǐn)慎使用的工具而不是一個(gè)黑箱魔法。當(dāng)你養(yǎng)成 stash 前加描述、恢復(fù)前先查看、定期清理?xiàng)５暮昧?xí)慣后你會(huì)發(fā)現(xiàn)這個(gè)“儲(chǔ)物柜”能讓你的開(kāi)發(fā)節(jié)奏變得無(wú)比從容。