注：这篇文章已被作者标注为“糟糕的文章”，不建议参考和阅读
情景：现在有2个分支，master和dev。dev是从master创建来的分支，我此时正在dev中胡搞毛搞... （实验对象为readme.txt文本）
master中的readme.txt文本原本是这样的：
我从master分支切换到dev，然后修改readme.txt：
工作才没开始多久，你刚在文本末加了一句 "It is branch dev."，老板就打电话给你，说你的master分支有个bug，限你要在5分钟内赶紧修好。
老板不知道我正忙着别的事情（他也不想知道），我只好接受这个任务，但是现在dev这边被我改了点东西，git status查看一下：
可见readme.txt被修改了，正常来说，修改了一个分支上的文件之后，如果要切换到其他分支，要先add和commit把修改后的文件提交到本地库。但我不想现在提交，因为我的工作还没做完呢，才完成了一点点。可要是现在就这样什么也不干地用指令git checkout master切换到master分支，我会发现master里面的readme.txt跟dev分支上修改后的readme.txt内容是一样的！这显然不是我想发生的事情。
master分支的readme.txt文件现在成这样了：
都怪刚刚没有在dev分支上修改了文件之后，add + commit提交文件到本地库。那么问题来了，有没有既不用先提交修改文件到本地库，又可以切换到master分支上进行正常地修改bug工作呢？那就是git stash功能了。它可以把当前工作现场“储存起来”，等以后恢复现场后继续工作。
我们重头来过：从刚刚在dev的readme.txt的文本末加了一句 "It is branch dev."这里开始。保存文件后查看git status：
执行git stash：（紧接着我执行了git stash list，用于查看）
现在再看一遍git status：
那个修改暂时“不见了”，我们现在打开readme.txt看一下内容：
看到的居然是master分支的readme.txt内容，可我明明还没有git checkout到master，而是在dev这个分支上啊，吓得我赶紧git branch了一下：
它告诉我，我是对的，我现在确实在dev分支上。至于为什么不是我们认识的那个dev，先不管它，按规则来，git checkout到master：
然后我们从master另创建一个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内容：
跟我们用git stash之后看到的内容是一样的。
要回到原来的工作现场，git stash pop：
看到文本最后一行就可以知道，我们又回来了，输入git stash list，不会返回任何信息：
再在下一行添加内容"Last line."之后 ， add + commit完，回到master分支。将dev合并到master，可能会出现以下几行提示：
#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行内容，但没有覆盖我们中途git stash之后在另一分支issue-1对master的bug的修改。可见git还是很贴心很好用的。
