背景

Git工作流

在我们的一个项目中，有3-4个人在同时开发，目前采用的是AoneFlow的变体进行分支管理，简单来说，分为四种类型的分支：主干分支(master)、特性分支(feature)、发布分支(release)、开发分支(develop/test)。

每当新功能需求过来后，会从master切出feature分支进行开发，开发完成后合并到test分支中进行测试。多个功能需求测试完成后，将对应的feature分支合并到release分支，再合并到master分支进行发布。如图：

这种开发模式下的特点：

test分支是一个“大杂烩”，所有开发完成（包括未测试完成）的feature分支都会合并到test分支。
master分支根据多个feature测试结果来进行选择性合并到release，作为当前版本最终需要发布的分支，合并到master进行上线发布。

问题

在最近一次项目代码合并的时候发现了两个问题：

一些新开发中的feature分支无法被合并到master分支，提示已经up-to-date。
把master分支往开发分支develop合并时发现部分代码被删除了。

回顾

错误的合并

在发现问题后, 经过一个小时的排查，终于发现在某次提交过程中，我们的一位开发不小心把test分支合并到了自己的featureA分支上。

这意味着，许多开发中的功能被合并到了featureA上。为了解决这个问题，这位同学通过对比，手动删除了多余的代码，保持了featureA分支只有自己开发的那部分代码，也经过测试通过了。

于是分支变成了这个样子：

发布上线

在上线代码合并到master的时候，我检查merge request进行例行的code-review，发现确实featureA 功能的提交，于是将featureA 合并到了master准备上线，上线后也没有任何问题。后续的功能也一个一个都提交上去了。

发现问题

几天后，一个同学像我反映，在一个新功能的开发中，基于master切出了featureD分支，开发完成后合并到test分支进行测试的时候，出现了很多不是自己开发的代码，我当时就很纳闷，这种模式下test分支永远是领先于master分支的，基于master的分支开发完成后提交到test应该只会有包含自己开发功能的那部分代码才对呀，最多是产生一些冲突，不会有太多的文件变更。

最初怀疑是不是拉错了分支，一看commit记录，发现了问题的根本原因：

在上次featureA 合并到master的时候，虽然没有多余的文件变更，但是featureA合并过test代码，即featureA包含了添加featureB/C, 删除featureB/C的两次commit记录

所以在后续基于Master拉出来的feature分支都会带上这个错误的commit记录，导致：

test分支上只有添加featureB的代码，基于master的新feature分支却带上了删除featureB的commit且领先于test，合并到test的时候会删除掉featureB的代码。
featureB分支再也无法合并到master分支，因为master上最新的commit已经删除了featureB的代码。

如何解决

方案一：在featureA 分支上revert 撤销那次合并test的Commit

git checkout featureA
git revert commit_id

提示失败了

原因是这个commit是一个merge commit，这次commit包含两个父节点，需要指定你要revert哪一个，即如果A，B合并到C,需要告诉git你要revert的是A提交还是B提交。这里使用 —m参数就可以了，1和2代表你要revert哪一个父提交，大多数情况是1，即撤销“刚才merge进来的那一个提交”

git revert commit_id -m 1

但是这里有个需要注意的地方，如果revert掉某次修改后，如果需要再次merge该分支, 需要再做一次反向revert。即Revert 掉之前的Revert，否则该分支之前的修改无法被提交，因为已经是“落后”于主干分支了。

方案二：在featureA 分支上reset掉那一次提交记录

reset和revert不同的是:

revert是根据某次的变更记录，生成一个新的commit，反向删除/添加对应之前某一次commit的代码。
reset是“消除”自己的commit记录重新提交，这种情况下如果reset提交到远程的分支，需要push -f强制更新，因此强烈不建议在多人协作的分支上这么做

这里要注意的是，如果在出错的commit版本后还有若干次正确的提交，reset后也会一并消失，需要重新加回来，不然后续正确的代码也会丢失，按照如下操作进行cherry-pick：

git reset --hard commit_id #退回到出错前的一个commit

git cherry-pick commit_id_right #将出错后的commit提交重新加回当前的时间轴

git push -f #强制更新

方案三：在featureA分支上进行rebase操作丢弃错误的提交

rebase即变基使用git rebase -i 命令可以压缩合并多次提交

格式：git rebase -i [startpoint] [endpoint]

其中-i的意思是interactive，即弹出交互式的界面让用户编辑完成合并操作，[startpoint] [endpoint]则指定了一个编辑区间，如果不指定[endpoint]，则该区间的终点默认是当前分支HEAD所指向的commit(注：该区间指定的是一个前开后闭的区间)。

操作方式为：

首先根据git log，找到出错前的一个commit
执行git rebase -i commit_id 合并之前的提交记录
会弹出一个vi编辑器如下：
将出错的那两次提交，pick改为drop，即丢弃。
Esc :wq保存
如果出现冲突
需要手动解决冲突后，执行
```
git add xxx
git rebase --continue
```

总结:

在多人合作中，尽量不要把test分支往feature分支上合并
多人协作的分支上出现已经提交到远程的错误的合并时，优先使用revert来进行错误回退，并注意后续分支再次合并是否有问题。
reset和rebase尽量在私人分支或者未提交到远程的时候使用，如果过去的分支已经提交到远程，会对其他人的本地分支造成影响。