git revert merge 问题

起因
在开发过程中,每个公司都有自己的一套分支管理办法,目前遇到的有两种,一种是 trunk 分支管理,一种是 dev、test、prod 这种递进式的分支管理 。两者各有优缺点:
前者: 就一个分支,没有频繁切换的烦恼,但是就是不利于测试阶段开发解决问题
后者:分支虽多,但是现在合并技术已经很成熟,可以很方便的合并,基本中规中矩 。
下面遇到的问题,就是在 trunk 管理的情况下,遇到了并行开发需求,然后将新需求的代码合并到了 trunk,导致 trunk 上多了一些新代码,但是库表没有支持上,会启动报错 。
这就是问题的起因 。
方法
一开始遇到问题,大家脑子里都能反映出 git和 git reset,但是都只是知道而已,没有人敢实操 。最终还是采用了 git reset 来解决的,我大概贴一下解决的流程 。
第一步: 备份现有分支

git revert merge 问题

文章插图
第二步:git reset 到 merge 发生的前一个提交,然后创建新分支
第三步 :在分支上由各自恢复自己之前的代码
第四步:使用分支,然后删除原有 trunk 分支,将合并到新 trunk
第五步:至此,问题解决
大家可以看到,这样解决问题,其实并不是很理想,还是需要丢弃之后的提交,会带来一定影响 。
其实,理想的办法是只丢弃有问题的提交,不要影响其它提交 。git 是提供了解决办法的,就是 git
对 git进行了一次专门的学习 。先给大家讲一下,再来说操作 。
因为 merge 不是一个单独的提交,而是两个分支合并到一起的,那么就会存在一个概念,一个主分支和一个次分支,比如: B合并到A,那么 A 就是主分支,B 就是次分支 。它们合并之后,会有一个新的提交,针对就会有两个父级分支 A 和 B,那么我们在对的提交进行的话,就会面临丢弃哪一个分支的选择,那么,我们只要选择丢弃问题的分支,就会解决问题 。
上面是用大白话把逻辑描述了一次,那么这次,给大家上个图:
git revert merge 问题

文章插图
第一步:git show
【git revert merge 问题】结果如下:
可以看到 merge 的记录有两个父分支,在对每一个分支的提交进行确认后,可以确定舍弃的分支 。
git revert
index 只能接收数字,代表舍弃第几个,最大为 的 id,对应到上面的例子,就是 git show 后面的
id
总结
至此,就全部解决完了,以此记录我职业生涯的第一次让自己觉得内疚的错误,希望大家引以为戒,不过呢,还是希望这篇文章对于所有人都没有用