一次Git撤销错误的Merge

---

title: once-git-merge-mistake-solve
date: 2018-04-20 23:37:00
tags:

• git

---

2018.4.20
简述：merge错了一个分支到测试分支上，发现后没有push。要撤销这次merge。
解决：（源于同事的友情帮助）bash 命令：

##检查
$ git status
##获取最新内容
$ git fetch --all
##强行reset到xxx分支的，这一步就相当于撤销了没有push的merge，IDEA和WebStorm等工具也有可选，如文后图
$ git reset --hard origin/xxx
$ git pull

2019.03.28

简述:

​ git分支流程: 简单说是根据不同的任务切不同的分支,提测时将同一天要发布的所有任务分支合到发布分支上, 当发布分支上有代码临时不上时就重开一个新的发布分支合并需要发布的那些任务分支。

​ 这次是发布分支废除了一次,但是有其他同事的代码个人分支混入了原发布分支的代码,所以预期后果会造成上线一部分不需要发布的代码。

​ 起初是我在用新发布分支合自己任务分支代码的时候发现已经有被合了, 这肯定不对劲,就找了当时切发布分支的同事, 核对后发现他的任务分支A中已误包含其他人的代码, 这显然是一次git使用事故了

排查解决:

刚开始用IDEA自带和其他git管理工具查看该分支提交日志,我的思路是先排查一遍Merge日志看看有没有直接从旧发布分支***release1***合到任务分支A的日志, 发现并没有。

​ 随后查看最近另一人的提交记录找出合代码比较晚的时间点进行排查, 如果有其他人的代码, 那么误操作肯定发生在这之后, 这样才能看到别人的提交日志, 排查出时间点大概为前一天下午15:32之后, 但是并没有排查出发生具体哪次操作,。

​ 于是我调整了一下思路, 从GItlab上查看改动提交时的文件改动,Gitlab可以查看某次提交时的当时所有文件的内容.所以可以 以某个发布分支中已知文件改动为标准筛选, 在两次commit之间从无到有, 那么可以判定误操作为后一次commit, 加上之前判定的发生最早时间点前一天15:32, 抽查了其中可能的commit后在第三次就马上找到了是前一天18:05的commit , 发现是另一同事的一次普通的常规commit(这居然是一次普通的commit 而不是合代码 惊了)。

​ 后来询问该同事, 发现事故原因竟然是, 用IDEA切分支的时候, 还没有完全切到另一个分支, 同时用Terminal进行了拉代码, 所以最终结果就是将***release1***分支的代码拉到了A任务分支本地,并且当作了一次正常的提交. 所以其实也是一次小小的并发延后问题。

​ 所以 在使用工具的时候还是要等进度条转完再进行操作,并在每次commit的时候检查一下,如果一次正常的commit需要提交比自己写的代码多得多的文件改动, 那么肯定是有问题了需要及时终止。