注：這篇文章已被作者標(biāo)注為“糟糕的文章”，不建議參考和閱讀
情景：現(xiàn)在有2個分支，master和dev。dev是從master創(chuàng)建來的分支，我此時正在dev中胡搞毛搞... （實驗對象為readme.txt文本）
master中的readme.txt文本原本是這樣的：
我從master分支切換到dev，然后修改readme.txt：
工作才沒開始多久，你剛在文本末加了一句 "It is branch dev."，老板就打電話給你，說你的master分支有個bug，限你要在5分鐘內(nèi)趕緊修好。
老板不知道我正忙著別的事情（他也不想知道），我只好接受這個任務(wù)，但是現(xiàn)在dev這邊被我改了點東西，git status查看一下：
可見readme.txt被修改了，正常來說，修改了一個分支上的文件之后，如果要切換到其他分支，要先add和commit把修改后的文件提交到本地庫。但我不想現(xiàn)在提交，因為我的工作還沒做完呢，才完成了一點點。可要是現(xiàn)在就這樣什么也不干地用指令git checkout master切換到master分支，我會發(fā)現(xiàn)master里面的readme.txt跟dev分支上修改后的readme.txt內(nèi)容是一樣的！這顯然不是我想發(fā)生的事情。
master分支的readme.txt文件現(xiàn)在成這樣了：
都怪剛剛沒有在dev分支上修改了文件之后，add + commit提交文件到本地庫。那么問題來了，有沒有既不用先提交修改文件到本地庫，又可以切換到master分支上進(jìn)行正常地修改bug工作呢？那就是git stash功能了。它可以把當(dāng)前工作現(xiàn)場“儲存起來”，等以后恢復(fù)現(xiàn)場后繼續(xù)工作。
我們重頭來過：從剛剛在dev的readme.txt的文本末加了一句 "It is branch dev."這里開始。保存文件后查看git status：
執(zhí)行g(shù)it stash：（緊接著我執(zhí)行了git stash list，用于查看）
現(xiàn)在再看一遍git status：
那個修改暫時“不見了”，我們現(xiàn)在打開readme.txt看一下內(nèi)容：
看到的居然是master分支的readme.txt內(nèi)容，可我明明還沒有g(shù)it checkout到master，而是在dev這個分支上啊，嚇得我趕緊git branch了一下：
它告訴我，我是對的，我現(xiàn)在確實在dev分支上。至于為什么不是我們認(rèn)識的那個dev，先不管它，按規(guī)則來，git checkout到master：
然后我們從master另創(chuàng)建一個issue-1分支，用于修改bug，修改完bug之后再把issue-1分支合并到master分支。為什么要這么麻煩，不直接在master分支里修改呢？？master分支不直接修改，它只能合并其他分支上的修改來更新。
切換到issue-1分支后修改老板所說的bug——把文本中第二句 a 的兩個雙引號去掉：
有事沒事git status一下總沒錯的：
接下來不用說都是 add + commit 了：
切換到master，順便看一下readme.txt：
將issue-1分支合并到master
搞定完bug，是時候干回dev分支里的事了：
此時的readme.txt內(nèi)容：
跟我們用git stash之后看到的內(nèi)容是一樣的。
要回到原來的工作現(xiàn)場，git stash pop：
看到文本最后一行就可以知道，我們又回來了，輸入git stash list，不會返回任何信息：
再在下一行添加內(nèi)容"Last line."之后 ， add + commit完，回到master分支。將dev合并到master，可能會出現(xiàn)以下幾行提示：
#Please enter a commit message to explain why this merge is necessary,
# especially if it merges an updated upstream into a topic branch.
這里可以先無視，輸入:wq即可退出
合并后的readme.txt：
看出保留了dev分支中新增的2行內(nèi)容，但沒有覆蓋我們中途git stash之后在另一分支issue-1對master的bug的修改。可見git還是很貼心很好用的。
