自己又试了一下，切换到dev分支后，先不stash pop，而是先git cherry-pick *******，然后再pop，这样就没问题了，文件也确实按照修改的来。确实还是要在理解的基础上，好好看error提示，多百度多google

git cherry-pick *******之后是要先提交之后才stash pop还是先stash pop呢？

按照教程还是有问题，如果修改的bug和stash的是同一个文件，先check-pick后再pop，那么原先修改后stash的内容要想commit就会出现冲突。对于新手突发情况很多，作者修改的都是readme文件就会发生这种情况。

个人认为原因是这样的：

①假定BUG所在的代码文件是A，并且A已经在dev分支上被修改了。

②在BUG分支上修改后，将代码文件A Merge到master分支上，然后commit。此时BUG所在代码文件A已经被commit一次了。

③返回到dev分支，想要将A中对应BUG的代码merge到dev分支中，但是A已经在dev分支上被修改了，所以Merge的时候会产生冲突。(尤其是BUG对应的代码和在dev中修改的代码是在同一处)

对于这种问题，我目前采用的是手动Merge。如果各位有更好的办法请留下你宝贵的意见。

教程确实有问题，按照楼主的方法解决了，需要先cherry-pick后stash pop

貌似只改同一个文件会有冲突，需要手动解决冲突，要是换成分别修改两个不同文件内容那两条指令执行顺序先后是没有问题的，难道是git以文件为单位操作的原因？

关于什么时候把改bug的id merge到dev分支，感觉是先后顺序的确没有明说，我把它理解是为了考验下新手们。。。

按楼主说的在回到dev分支先cherry-pick，没有报错，也的确改了。再pop，报错了

$ git stash pop

Auto-merging README.md

CONFLICT (content): Merge conflict in README.md

The stash entry is kept in case you need it again.

看readme文件，就是stash之前的跟改过的冲突。只能把不要的删了提交。。。感觉还不如直接改。

只能说改一个分支上的同一个文件，有点坑