最近在使用Git管理項目工程的時候，遇到了很多問題，也學(xué)習(xí)到了很多關(guān)于Git常見使用的技巧，下面就其中關(guān)于Git Stash的用法和大家分享下。
首先，簡單介紹下Git Stash命令的用法，詳細的用法在man文檔中有相關(guān)介紹，下面我來說明常見的使用。
git stash: 備份當前的工作區(qū)的內(nèi)容，從最近的一次提交中讀取相關(guān)內(nèi)容，讓工作區(qū)保證和上次提交的內(nèi)容一致。同時，將當前的工作區(qū)內(nèi)容保存到Git棧中。
git stash pop: 從Git棧中讀取最近一次保存的內(nèi)容，恢復(fù)工作區(qū)的相關(guān)內(nèi)容。由于可能存在多個Stash的內(nèi)容，所以用棧來管理，pop會從最近的一個stash中讀取內(nèi)容并恢復(fù)。
git stash list: 顯示Git棧內(nèi)的所有備份，可以利用這個列表來決定從那個地方恢復(fù)。
git stash clear: 清空Git棧。此時使用gitg等圖形化工具會發(fā)現(xiàn)，原來stash的哪些節(jié)點都消失了。
關(guān)于Git Stash的詳細解釋，適用場合，這里做一個說明：
使用git的時候，我們往往使用branch解決任務(wù)切換問題，例如，我們往往會建一個自己的分支去修改和調(diào)試代碼, 如果別人或者自己發(fā)現(xiàn)原有的分支上有個不得不修改的bug，我們往往會把完成一半的代碼 commit提交到本地倉庫，然后切換分支去修改bug，改好之后再切換回來。這樣的話往往log上會有大量不必要的記錄。其實如果我們不想提交完成一半或者不完善的代碼，但是卻不得不去修改一個緊急Bug，那么使用'git stash'就可以將你當前未提交到本地（和服務(wù)器）的代碼推入到Git的棧中，這時候你的工作區(qū)間和上一次提交的內(nèi)容是完全一樣的，所以你可以放心的修 Bug，等到修完Bug，提交到服務(wù)器上后，再使用'git stash apply'將以前一半的工作應(yīng)用回來。也許有的人會說，那我可不可以多次將未提交的代碼壓入到棧中？答案是可以的。當你多次使用'git stash'命令后，你的棧里將充滿了未提交的代碼，這時候你會對將哪個版本應(yīng)用回來有些困惑，'git stash list'命令可以將當前的Git棧信息打印出來，你只需要將找到對應(yīng)的版本號，例如使用'git stash apply stash@{1}'就可以將你指定版本號為stash@{1}的工作取出來，當你將所有的棧都應(yīng)用回來的時候，可以使用'git stash clear'來將棧清空。
在這里順便提下git format-patch -n , n是具體某個數(shù)字， 例如 'git format-patch -1' 這時便會根據(jù)log生成一個對應(yīng)的補丁，如果 'git format-patch -2' 那么便會生成2個補丁，當然前提是你的log上有至少有兩個記錄。
看過上面的信息，就可以知道使用場合了：當前工作區(qū)內(nèi)容已被修改，但是并未完成。這時Boss來了，說前面的分支上面有一個Bug，需要立即修復(fù)。可是我又不想提交目前的修改，因為修改沒有完成。但是，不提交的話，又沒有辦法checkout到前面的分支。此時用Git Stash就相當于備份工作區(qū)了。然后在Checkout過去修改，就能夠達到保存當前工作區(qū)，并及時恢復(fù)的作用。
下面，將我使用過程中遇到的一個問題和大家分享：
首先，在Git Stash之后，提交圖如下所示：
從圖中可以看到，develop和newdevelop是在同一個分支上，因為分支newdevelop是在develop分支的基礎(chǔ)上開發(fā)的。想加入一個新的特性，所以就開了newdevelop分支，然后就在上面加?xùn)|西，加特性，該代碼。這個時候工作的內(nèi)容已經(jīng)變化了，但是develop和newdevelop都是指向同一個提交的，因為newdevelop上面還木有提交。
這個時候，Boss來了，說develop上面有個Bug，趕快改一下，手頭的工作先放放，穩(wěn)定版本不能有缺陷。沒辦法，當前正在newdevelop上搞的high呢，就Git Stash一下。所以會看到上面有兩個節(jié)點，紅色以及上面一個。就是stash之后的結(jié)果，注意是在newdevelop上面進行的stash。
正如前面所說，stash會暫存當前的工作區(qū)內(nèi)容，然后將工作區(qū)內(nèi)容保持和上次提交相同，此時內(nèi)容都是上面8a32那個提交的內(nèi)容。從終端中查看相應(yīng)的信息內(nèi)容，如下：
印證了簽名的說法，newdevelop是有修改，modified，然后stash之后，工作區(qū)是最近一次提交，此時newdevelop和develop都是相同的，所以再git status查看發(fā)現(xiàn)，都一樣，nothing to commit.
然后Stash完成之后，就要Fix Bug了。為此，回到develop分支上進行修復(fù)，然后提交，完成后的提交圖如下所示：
從途中可以看到，newdevelop還是在下面，因為指向的是老的那個8a32的commit。新的develop由于修復(fù)了Bug，所以產(chǎn)生一個新提交。
然后在develop上面修復(fù)了Bug之后，在回到newdevelop上面進行一個新的特性的繼續(xù)編碼，此時checkout回去的時候，沒有神馬內(nèi)容可以提交，因為都存在Stash中了，沒有任何修改。如上圖。
那么，恢復(fù)工作區(qū)內(nèi)容吧。于是git stash pop（注意這里由于只Stash了一次所以使用pop，具體你存放了多少，要恢復(fù)哪一個要自己清楚，否則會出錯?。?br />
恢復(fù)之后，從上圖中可以看到，此時再git status就會發(fā)現(xiàn)文件有修改，說明恢復(fù)過來了。然后就繼續(xù)編碼，提交一個穩(wěn)定的新特性版本，如下圖，產(chǎn)生的新提交為0906.
然后再查看提交圖，會發(fā)現(xiàn)，stash pop之后，對應(yīng)的存放的stash被清空掉了，提交圖中，newdevelop上面對應(yīng)一個新的提交。并且在develop上面。分支的develop那個紅色，即為前面修復(fù)Bug的那個提交。
總結(jié)起來：
操作很簡單，但是頭腦要清楚。要在哪個分支上修復(fù)Bug，要暫存哪個地方的內(nèi)容，之后修復(fù)完了在那個地方提交，然后要到哪個分支上面恢復(fù)工作區(qū)，都是需要注意的，否則，很容易造成提交圖混亂。只有弄清楚了工作流程，才不容易出錯，才能保證很高的工作效率。
最后一句：Git是神器，就要看你如何駕馭它了。
posted on 2011-11-13 00:36
deercoder 閱讀(300825)
評論(21) 編輯 收藏 引用 所屬分類:
Git