git revert merge 问题 _git

起因
在开发过程中，每个公司都有自己的一套分支管理办法，目前遇到的有两种，一种是 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
【git revert merge 问题】结果如下：
可以看到 merge 的记录有两个父分支，在对每一个分支的提交进行确认后，可以确定舍弃的分支。
git revert
index 只能接收数字，代表舍弃第几个，最大为的 id，对应到上面的例子，就是 git show 后面的
id
总结
至此，就全部解决完了，以此记录我职业生涯的第一次让自己觉得内疚的错误，希望大家引以为戒，不过呢，还是希望这篇文章对于所有人都没有用