git中的bug管理

场景：正在自己的dev分支上工作的小T突然接到紧急修改bug的任务，但是手中的代码还没完成，并不想直接提交，于是她打算暂时存到堆栈区，等到bug修复完毕再继续完成代码。

修复bug流程：

1. (dev)git stash (贮藏自己工作分支的内容到堆栈区）
2. (master)git checkout -b issue-1 (从master分支创建一个分支修改bug)
3. (issue-1)手动修复完bug之后add 并且 commit. 记住输出的版本号。
4. (master)git merge --no-ff -m “fixed master bug” issue-1 (合并分支并提交，即修复master分支上的bug）
5. (dev)git stash pop(恢复自己的工作现场）
6. (dev)git cherry-pick 记住的版本号(master出现的bug可能在自己的工作分支中也存在，“复制”刚刚的修改内容）
7. 打扫现场。删除issue-1分支，并确认bug是否正确修复。

以上流程针对bug文件和你正在编写的文件不同的情况。

如果非常不幸地是同一个文件
修复dev中的bug后进行git stash pop将会显示错误1：内容冲突

先git stash pop再修复dev中的bug将会显示错误2：未完成的代码将被覆盖

错误原因
不管是先改bug还是先还原现场，dev分支(当前工作分支）编写的文件和修复的bug文件在同一个文件，内容都会出现冲突。
解决方法
手动解决冲突，接受传入的更改（即修复bug前的文件内容），然后git stash pop。当然bug也得自己在dev里重新修改了。
千万不要直接git stash drop抛弃堆栈区内容，那之前还未提交的dev分支代码也将被丢弃，在不修复bug和丢弃刚刚写到一半的代码还是选择前者，然后自己在恢复后的工作现场里面手动修改bug。

总结：bug文件和工作文件不是同一个文件时，可以在修改完master分支的bug后借助cherr-pick 版本号 迅速修改完自己工作分支的bug。如果恰好是同一个文件，那只能恢复工作现场后自己手动修复bug。