软件开发中，bug就像家常便饭一样，有了bug就需要修复，在Git中，由于分支是如此的强大，所以每个bug通过一个新的分支来修复，在修复后，合并分支，然后将临时分支删除。
当你接到一个修复代号为119的bug时，很自然的想建立一个分支issue-119来修复它，但是，当前在dev上进行的工作还没有提交。
LV@LV-PC MINGW32 /c/gitskill (dev)
$ git status
On branch dev
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
new file: hello.txt
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: readme.txt
并不是你不想提交，而是工作进行到一半，还没法提交，预计完成时间还需要半天的时间，但是你必须在一个小时内修复该bug,怎么办？
幸运的是，Git还提供了一个stash功能，可以把当前工作现场“储藏”起来，等以后恢复现场后继续工作：
LV@LV-PC MINGW32 /c/gitskill (dev)
$ git stash
Saved working directory and index state WIP on dev: 4f4f23a dev commit
HEAD is now at 4f4f23a dev commit
现在用git status查看工作区，就是干净的，因此可以放心的创建分支来修复Bug
LV@LV-PC MINGW32 /c/gitskill (dev)
$ git status
On branch dev
nothing to commit, working directory clean
首先确定在哪个分支上修复bug,假定需要在master分支上修复，就从master分支上创建临时分支：
LV@LV-PC MINGW32 /c/gitskill (dev)
$ git checkout master
Switched to branch 'master'
Your branch is up-to-date with 'origin/master'.
LV@LV-PC MINGW32 /c/gitskill (master)
$ git checkout -b issue-119
Switched to a new branch 'issue-119'
现在修复bug，将在readme.txt中添加“bug修复完成”
$ cat readme.txt
master分支内容
添加dev分支内容
master分支上的合并测试内容
分支合并测试
dev分支--no-ff方式的merge
bug修复完成
LV@LV-PC MINGW32 /c/gitskill (issue-119)
$ git add readme.txt
LV@LV-PC MINGW32 /c/gitskill (issue-119)
$ git commit -m "bug 119 had fix"
[issue-119 b4d16ef] bug 119 had fix
1 file changed, 1 insertion(+)
修复完成后，切换到master分支，并完成合并，最后删除issue-119
LV@LV-PC MINGW32 /c/gitskill (issue-119)
$ git checkout master
Switched to branch 'master'
Your branch is up-to-date with 'origin/master'.
LV@LV-PC MINGW32 /c/gitskill (master)
$ git merge --no-ff -m "merge bug fix 119" issue-119
Merge made by the 'recursive' strategy.
readme.txt | 1 +
1 file changed, 1 insertion(+)
LV@LV-PC MINGW32 /c/gitskill (master)
$ git branch -d issue-119
Deleted branch issue-119 (was b4d16ef).
bug已经修复了，现在是时候回到dev分支上干活了
LV@LV-PC MINGW32 /c/gitskill (master)
$ git checkout dev
Switched to branch 'dev'
LV@LV-PC MINGW32 /c/gitskill (dev)
$ git status
On branch dev
nothing to commit, working directory clean
工作区是干净的，刚才的工作区存到哪里去了？用git stash list命令看看：
LV@LV-PC MINGW32 /c/gitskill (dev)
$ git stash list
stash@{0}: WIP on dev: 4f4f23a dev commit
工作现场还在，Git把stash内容存到某个地方了，但是需要恢复一下，有两种方法：
1.用git stash apply恢复，但是恢复后，stash内容并不删除，你需要用git stash drop来删除。
2.用git stash pop，恢复的同时把stash内容也删除了。
LV@LV-PC MINGW32 /c/gitskill (dev)
$ git stash list
stash@{0}: WIP on dev: 4f4f23a dev commit
LV@LV-PC MINGW32 /c/gitskill (dev)
$ git stash apply stash@{0}
On branch dev
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
new file: hello.txt
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: readme.txt
LV@LV-PC MINGW32 /c/gitskill (dev)
$ git stash list
stash@{0}: WIP on dev: 4f4f23a dev commit
LV@LV-PC MINGW32 /c/gitskill (dev)
$ git stash drop stash@{0}
Dropped stash@{0} (8f8d8fbddf55ed37d505eeca7371f78e705a4daa)
LV@LV-PC MINGW32 /c/gitskill (dev)
$ git stash list
查看工作区：
LV@LV-PC MINGW32 /c/gitskill (dev)
$ git status
On branch dev
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
new file: hello.txt
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
我们又回到了修复bug之前了
小结：我们修复bug时，我们创建新的bug分支进行修复，然后合并，最后删除；
当手头上的工作没有完成时，先把工作现场git stash一下，然后去修复bug，修复后，再git stash pop ,回到工作现场。