git merge使用不当引起的代码丢失血案

背景

几年前大批量的团队都在转用git，git的本地库和分支特性让代码管理的便利性大大增长，也由于本地库和分支的大批量使用致使了代码之间的频繁merge，咱们团队之前就有遇到过git merge之后丢代码的状况，表现就是某些变动开发A提交了，通过中间以序列的commit, merge，push，最终某些改动没了，去看commit history，也没有相应的变动记录。一次次commit对比之后老是会找到某次的merge，可是也无法解释为何会丢，最后为了保险一般会选择beyond compare全量对比一次确保全部丢失的代码找回来，那是一个痛苦而又让人睡不安稳的解决办法。

今天又遇到了一次这个问题，此次的更加诡异，在我查为何丢的时候，另一个同事提交代码之后居然丢失的代码回来了，我当时脑壳里面只想到一个词，那就是： 见鬼。可是冷静下来想，git这种工具出现真丢代码的几率确定很小，确定是咱们姿式不对。因而认认真真的研究了咱们今天的提交记录，终于找到答案，就是git merge后只提交部分代码致使的，这里顺带提一下，git pull等于git fetch + git merge，因此git pull时也须要特别关注本文提到的问题。

验证过程

为了验证这个问题，我建了一个全新的git库来复现上述问题，根据咱们遇到的状况模拟，整个过程我使用三个用户模拟交叉提交和合并，分别是user1，user2，user3，为了方便我没有选择注册三个号，而是在提交信息里面都带上了名字，能够制造两次代码冲突，而且两次都进行部分提交。最终的代码提交记录以下：

为了更清晰的看到这个提交过程，我将三个用户的提交分开来，并根据提交前后作了下面的图。

代码怎么丢的？

首先，第1步和第2步，user1和user2分别在本地作修改，共同修改了file1，只有user2对file2也作了修改，因此若是这两人的代码合并，能够预计合并的时file1会冲突，file2不会。user2修改完成之后作了一次git push，这时候git远端库的head应该是指向user2的最后一次提交的。接着user1作git pull，由于file1被两个用户修改了，因此须要合并，接着user1处理完冲突之后只提交了file1，没有提交file2（用命令行须要手动reset，可是用有些GUI工具是能够选择只提交file1的）。此时的库已经丢失了user2:file2:add line的那次改动，这就是血案的开始，丢代码。能够对比一下 merge前 和merge后 。

代码怎么"恢复"的？

前面只是验证了代码怎么丢，可是事情没有结束，我上面提到更诡异的是代码恢复了，这又是怎么回事呢？user1在第3步合完代码之后，本身进行了两次提交，修改了file3和file1，同时，user3加入并本地修改了file1（预计会和user1冲突），接着user1git push，而后user3 git pull，这时候会报file1冲突，一样，user3犯了user1相似的错误，只提交了冲突文件file1。按第3步丢代码的经验，file3的改动确定是没有了，验证之后确实如此，可是再看看file2的变动呢，它居然又回来了，因此所谓的恢复不是恢复，所谓的丢失没有丢失，就问你怕不怕。更可怕的是咱们再去看file2的变动历史。

中间消失和恢复的过程没有任何变动记录，这也是以前咱们常常查到无法往下查到地方。从表现上看，是第一次误操做忽略了这一行的变动，而第二次误操做，能够理解为是忽略了忽略添加这一行的那一次变动，可是，全部的都没有记录。

总结

上面的实验可能看起来有点繁琐，总结一下，核心的问题就是不要在git merge的时候只提交部分代码，特别是好多人刚刚用git的时候，运行完成一次git merge，发现本身修改了1个文件，结果git提示要提交100个，这时候当心谨慎的新同窗就会选择只提交本身的变更吧，却不知这是在犯大错啊。除了这种状况，以前还遇到有的新同窗会修改git默认生成的merge信息，这也是很是很差的习惯，改了之后在查问题的时候没办法很容易的看到哪些是merge。因此请注意：

• git merge之后不要部分提交！！

• git merge之后不要部分提交！！

• git merge之后不要部分提交！！

• git merge的信息不要手动改！！

• git merge的信息不要手动改！！

• git merge的信息不要手动改！！

文中提到的实验库的地址是： find-the-missing-code, 有兴趣的童鞋能够本身详细看一下。

本文转载自： git merge使用不当引起的代码丢失血案@blog.23lab.com

 

亲，若是您感受本文有用，请点个赞再走吧✌(>‿◠)！！