git revert merge 问题

起因

在开发过程中，每个公司都有自己的一套分支管理办法，目前遇到的有两种，一种是 trunk 分支管理， 一种是 dev、test、prod 这种递进式的分支管理。 两者各有优缺点：

前者： 就一个分支，没有频繁切换的烦恼， 但是就是不利于测试阶段开发解决问题

后者：分支虽多，但是现在合并技术已经很成熟，可以很方便的合并，基本中规中矩。

下面遇到的问题，就是在 trunk 管理的情况下，遇到了并行开发需求，然后将新需求的代码合并到了 trunk ，导致 trunk 上多了一些新代码，但是库表没有支持上，会启动报错。

这就是问题的起因。

方法

一开始遇到问题，大家脑子里都能反映出 git 和 git reset ， 但是都只是知道而已，没有人敢实操。 最终还是采用了 git reset 来解决的， 我大概贴一下解决的流程。

第一步： 备份现有分支

第二步：git reset 到 merge 发生的前一个提交，然后创建新分支

第三步 ：在 分支上由各自恢复自己之前的代码

第四步：使用 分支，然后删除原有 trunk 分支， 将 合并到新 trunk

第五步：至此，问题解决

大家可以看到， 这样解决问题，其实并不是很理想，还是需要丢弃之后的提交，会带来一定影响。

其实，理想的办法是只丢弃有问题的提交，不要影响其它提交。 git 是提供了解决办法的， 就是 git

对 git 进行了一次专门的学习。 先给大家讲一下，再来说操作。

因为 merge 不是一个单独的提交， 而是两个分支合并到一起的， 那么就会存在一个概念，一个主分支和一个次分支， 比如： B合并到A， 那么 A 就是主分支，B 就是次分支。它们合并之后，会有一个新的提交 ，针对 就会有两个父级分支 A 和 B，那么我们在对 的提交进行 的话，就会面临丢弃哪一个分支的选择，那么，我们只要选择丢弃问题的分支，就会解决问题。

上面是用大白话把逻辑描述了一次，那么这次，给大家上个图：

第一步：git show

结果如下：

可以看到 merge 的记录有两个父分支，在对每一个分支的提交进行确认后，可以确定舍弃的分支。

git revert  

index 只能接收数字，代表舍弃第几个，最大为 的 id， 对应到上面的例子，就是 git show 后面的

id

总结

至此，就全部解决完了，以此记录我职业生涯的第一次让自己觉得内疚的错误，希望大家引以为戒， 不过呢，还是希望这篇文章对于所有人都没有用