Git Bug分支、stash

开发进行时，bug四处寻。

每一次的开发都是会出bug这个令人"悲愤"的玩意，且每一次的调试总是那么耐人寻味。

同样，在我们的Git里面，也有个bug，不过此bug非bug，这是一个用来修复bug的分支。

说到分支，理应想到这一系列操作。创建分支、合并分支、解决冲突、删除分支。

同样的，bug分支也是这一系列操作，只是它多了几个命令。我们先测试一番：

我们假定要修复一个bug叫：issue-01.txt,内容为：bug 1

然后我们需要在master上修复这个bug，但是我们在dev上依旧在进行开发，且未把功能实现，所以无法提交。

这时候就需要先在dev分区输入这个命令了：

git stash

我们先看看输入git stash之前工作区的状态：

它提示，有一个 dev.txt进行了改动文件且尚未提交。我们看看dev的内容变化情况：

这是目前的内容。

再输入 git stash 后的内容变成了：

git stash ...dev..内容不见了？千万不要急，它只是把当前工作现场"储藏"起来了，当我们恢复现场后，依旧可以看到"git stash ...dev.."这些内容：

git stash pop

输入这个命令，恢复现场并删除stash内容。

或许你会问什么是stash内容，看图演示，这个是删除了stash内容的list：

什么都没有，是的，因为删除了，所以什么都没有。我们不删除stash内容，并恢复现场试一试：

git stash apply

输入list命令后，发现多了数据，这就是stash内容。当输入完 apply 后，如果想删除stash内容，使用:

git stash drop

它就会删除stash的内容。理解了stash的使用后，bug分支修复，就更加简单了。

假定我们去master分支上修复：

dev没有stash的情况下它会切换分支出错，如果commit就可能会引起冲突，所以这就是stash最大的用途，完美避免了冲突。

然后我们在master分支下创建一个issue-01的bug分支，用于修复bug：

创建完成，修改上一章节clash.txt的内容：

然后提交、合并、删除分支：

现在，bug就已经修复完了。然后再去dev 恢复现场，完成所有操作，

什么是：另一种合并命令。它有它的名称，下一章再讲解。

now，0.33分，晚安。

请勿熬夜哦！