我们往往拿master分支作为稳定版分支，然后基于master分支checkout出feature分支进行各自的需求开发。一旦开发完成就会往master分支上进行merge,然后才上线,这也是常见的一种git流程。
最近同事遇到一个场景需要进行回滚,怎么回滚都很别扭,特此记录一下。
master分支某个tag上线之后,又经理了几次迭代,这期间又有个同学A往master分支merge过代码并发布,好巧不巧某个功能一开始没有发现问题,大家都以为没有问题，中间又有AB两个同学各自提交了一些代码并发布，有一天同学B往master分支merge了自己的功能需求代码并进行了发布，好巧不巧这时候发现A同学的功能有bug。这时候走hotfix分支紧急修复是来不及了，按理说找到之前有Bug的那一次merge然后直接revert就行。但是偏偏A同学也不确认究竟是哪一次merge引入的这个问题，中间又引入了好几个同学的merge，而且直接revert还是得解冲突，因为后续的一个merger依赖之前的merge，要revert必须全部相关的merge统统revert
master 分支某个稳定版之后有很多同学把自己的代码合并到了master分支并进行了上线，后来发现某个同学的功能有bug，这时候如果回滚到该同学之前的某个版本的话，那其他同学在他之后的所有 commit 和 merge 都会丢失，也就是别人写的功能也跟着回滚了。这个时候最好的方式是只revert有bug的哪些commit 或者 merge。这里如果忘稳定版master分支合并用的是rebase策略就不容易处理了，因为你必须摘出哪些是需要回滚的commit，如果用的是merge策略就好多了，直接revert某个commit就行。
