Git stash

最近在使用Git管理項目工程的時候，遇到了不少問題，也學習到了不少關於Git常見使用的技巧，下面就其中關於Git Stash的用法和你們分享下。
首先，簡單介紹下Git Stash命令的用法，詳細的用法在man文檔中有相關介紹，下面我來講明常見的使用。
git stash: 備份當前的工做區的內容，從最近的一次提交中讀取相關內容，讓工做區保證和上次提交的內容一致。同時，將當前的工做區內容保存到Git棧中。
git stash pop: 從Git棧中讀取最近一次保存的內容，恢復工做區的相關內容。因爲可能存在多個Stash的內容，因此用棧來管理，pop會從最近的一個stash中讀取內容並恢復。
git stash list: 顯示Git棧內的全部備份，能夠利用這個列表來決定從那個地方恢復。
git stash clear: 清空Git棧。此時使用gitg等圖形化工具會發現，原來stash的哪些節點都消失了。
關於Git Stash的詳細解釋，適用場合，這裏作一個說明：

使用git的時候，咱們每每使用branch解決任務切換問題，例如，咱們每每會建一個本身的分支去修改和調試代碼, 若是別人或者本身發現原有的分支上有個不得不修改的bug，咱們每每會把完成一半的代碼 commit提交到本地倉庫，而後切換分支去修改bug，改好以後再切換回來。這樣的話每每log上會有大量沒必要要的記錄。其實若是咱們不想提交完成一半或者不完善的代碼，可是卻不得不去修改一個緊急Bug，那麼使用'git stash'就能夠將你當前未提交到本地（和服務器）的代碼推入到Git的棧中，這時候你的工做區間和上一次提交的內容是徹底同樣的，因此你能夠放心的修 Bug，等到修完Bug，提交到服務器上後，再使用'git stash apply'將之前一半的工做應用回來。也許有的人會說，那我可不能夠屢次將未提交的代碼壓入到棧中？答案是能夠的。當你屢次使用'git stash'命令後，你的棧裏將充滿了未提交的代碼，這時候你會對將哪一個版本應用回來有些困惑，'git stash list'命令能夠將當前的Git棧信息打印出來，你只須要將找到對應的版本號，例如使用'git stash apply stash@{1}'就能夠將你指定版本號爲stash@{1}的工做取出來，當你將全部的棧都應用回來的時候，可使用'git stash clear'來將棧清空。
在這裏順便提下git format-patch -n , n是具體某個數字， 例如 'git format-patch -1' 這時便會根據log生成一個對應的補丁，若是 'git format-patch -2' 那麼便會生成2個補丁，固然前提是你的log上有至少有兩個記錄。

看過上面的信息，就能夠知道使用場合了：當前工做區內容已被修改，可是並未完成。這時Boss來了，說前面的分支上面有一個Bug，須要當即修復。但是我又不想提交目前的修改，由於修改沒有完成。可是，不提交的話，又沒有辦法checkout到前面的分支。此時用Git Stash就至關於備份工做區了。而後在Checkout過去修改，就可以達到保存當前工做區，並及時恢復的做用。
下面，將我使用過程當中遇到的一個問題和你們分享：
首先，在Git Stash以後，提交圖以下所示：

從圖中能夠看到，develop和newdevelop是在同一個分支上，由於分支newdevelop是在develop分支的基礎上開發的。想加入一個新的特性，因此就開了newdevelop分支，而後就在上面加東西，加特性，該代碼。這個時候工做的內容已經變化了，可是develop和newdevelop都是指向同一個提交的，由於newdevelop上面還木有提交。
這個時候，Boss來了，說develop上面有個Bug，趕快改一下，手頭的工做先放放，穩定版本不能有缺陷。沒辦法，當前正在newdevelop上搞的high呢，就Git Stash一下。因此會看到上面有兩個節點，紅色以及上面一個。就是stash以後的結果，注意是在newdevelop上面進行的stash。
正如前面所說，stash會暫存當前的工做區內容，而後將工做區內容保持和上次提交相同，此時內容都是上面8a32那個提交的內容。從終端中查看相應的信息內容，以下：

印證了簽名的說法，newdevelop是有修改，modified，而後stash以後，工做區是最近一次提交，此時newdevelop和develop都是相同的，因此再git status查看發現，都同樣，nothing to commit.
而後Stash完成以後，就要Fix Bug了。爲此，回到develop分支上進行修復，而後提交，完成後的提交圖以下所示：

從途中能夠看到，newdevelop仍是在下面，由於指向的是老的那個8a32的commit。新的develop因爲修復了Bug，因此產生一個新提交。

而後在develop上面修復了Bug以後，在回到newdevelop上面進行一個新的特性的繼續編碼，此時checkout回去的時候，沒有神馬內容能夠提交，由於都存在Stash中了，沒有任何修改。如上圖。
那麼，恢復工做區內容吧。因而git stash pop（注意這裏因爲只Stash了一次因此使用pop，具體你存放了多少，要恢復哪個要本身清楚，不然會出錯！）

恢復以後，從上圖中能夠看到，此時再git status就會發現文件有修改，說明恢復過來了。而後就繼續編碼，提交一個穩定的新特性版本，以下圖，產生的新提交爲0906.
而後再查看提交圖，會發現，stash pop以後，對應的存放的stash被清空掉了，提交圖中，newdevelop上面對應一個新的提交。而且在develop上面。分支的develop那個紅色，即爲前面修復Bug的那個提交。

總結起來：
操做很簡單，可是頭腦要清楚。要在哪一個分支上修復Bug，要暫存哪一個地方的內容，以後修復完了在那個地方提交，而後要到哪一個分支上面恢復工做區，都是須要注意的，不然，很容易形成提交圖混亂。只有弄清楚了工做流程，纔不容易出錯，才能保證很高的工做效率。
最後一句：Git是神器，就要看你如何駕馭它了。