【问题处理】GIT合并解决冲突后，导致其他人代码遗失的排查

📕作者简介：战斧，从事金融IT行业，有着多年一线开发、架构经验；爱好广泛，乐于分享，致力于创作更多高质量内容
📗本文收录于 GIT 专栏，有需要者，可直接订阅专栏实时获取更新
📘高质量专栏 云原生、RabbitMQ、Spring全家桶 等仍在更新，欢迎指导
📙Zookeeper Redis kafka docker netty等诸多框架，以及架构与分布式专题即将上线，敬请期待

---

项目场景

同事目前在当前分支进行开发，主分支经历了比较大的改动，为了防止当前分支合并进主分支时有较多的冲突，所以开发完成后，仅提交到本地仓库，然后开发人员就尝试把主分支先合并进当前分支，相当于更新一下当前分支，最后再推送，结果合并冲突后，其他人代码的修改却奇怪的遗失了。

---

问题描述

为了搞清楚问题是如何发生的，我让其重现了一下他的操作，先把本地的当前分支和目标分支都更新到最新，然后使用IDEA自带的Merge into Current命令，想要把目标分支合并到当前分支

然后不出所料的发生了冲突，并弹出了冲突框

然后在弹出的框中，解决掉所有冲突，并点击Apply按钮

然而，此刻右下角冒出了一个警告

但是与此同时，目标的所有提交已经进入到工作区，把文件都修改掉了

此时，当尝试进行提交时，要提交的不仅是我们的内容，还包含了目标分支的内容，如图，当前分支其实只改了两个文件，但现在要提交的变成了数百个。

开发人员此时仅勾选了自己修改的两个文件进行了递交，成功解决了冲突，随之进行了推送。最终导致主分支上仅有自己的代码，其余同事的代码全部丢失了

---

分析与处理：

1. 警告分析

首先我们分析警告的内容，显示的是要在提交信息中输入修改单号。这个提示是我们在hook中设置的提示

这个提示本身没问题，但问题是，它的校验仅针对手动commit，此时它会校验提交内容。在合并的过程中虽然从底层来说，也会生成一个合并提交点，但毕竟不是commit，因此不会导致这种问题。

换句话说，这个提示是正常的。因为merge发生冲突后，会暂停，需要手工解决冲突后，开发者自行commit，此处IDEA的的APPLY按钮其实会帮我们进行commit，当然，它的commit信息肯定不会有什么修改单号，因而触发了这种提示 。所以，这是正常现象。

2. 文件分析

从IDEA中我们看到了上面的很多文件是待提交，其实用命令也能达到相同的效果，比如我们可以使用git status来检查一下

可以看到关键文字：

All confilct fixed but you are still merging

这段文字就是正常合并冲突后出现的，说明我们的合并其实并没有问题，解决冲突也没有问题，它下面这么多文件除了包含我们自己修改的文件，还包含了其他分支的修改记录。

3. 问题关键

既然合并本身，和解决冲突都没有问题，那问题出在哪呢？其实就出在最后进行提交的时候，开发同学因为觉得其他代码不是自己写的，所以并没有勾选，仅提交了自己写的那两个文件。

殊不知，对于GIT来说，你不勾选他们的提交其实就相当于放弃了那些修改，当你最后把你的这次提交推送到主分支时，主分支就会遵循你的指令，用你此刻的文件状态覆盖掉原有的文件，相当于说，将那些文件的修改全都回退掉了

4. 验证

在demo工程上进行验证，在master分支修改并提交两个文件，而在master_copy分支修改其中一个文件的同一行，这样在master_copy分支进行merge，会产生一个文件冲突，两个文件待提交。如果我们只提交一个文件，然后再从master分支把它合并回来，就会发现另外一个文件的修改丢失了

---

解决策略

既然事故已经发生，我们现在还是需要来解决的，解决的办法其实很简单，两种思路：

第一种让开发者把那些未提交的内容再次提交，再次合并进来即可。但这样的话，这些文件的递交者就会变成开发者，而不是它们原来的修改者了。

第二种就是还原，然后让开发者重新操作了。首先把master 和 master_copy 的分支还原，即还原到merge之前，然后重新合并，重新解决冲突，重新提交即可

总结

这次事故其实也有巧合的因素，因为公司有提交信息校验，所以导致合并冲突时，IDEAj解决冲突后的提交操作被拦截。导致需要开发手动进行提交，而恰巧合并的提交和普通的代码提交不一样，有一定的特殊性，所要提交的内容其实是两个分支与公共祖先的所有不同代码。如果开发者预先不知道这种情况，仅勾选你此次修改的部分来提交，相当于其他分支的修改被你放弃了。这将导致其他人的代码丢失

所以GIT的操作还是要三思而后行，尤其是发现出了问题不知道该怎么办时，及时向其他同事咨询，避免事态恶化