（转）Git Stash用法，方便临时处理bug时随时切换分支而不丢失修改

最近在使用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是神器，就要看你如何驾驭它了。