原文： git merge使用不当引发的代码丢失血案@blog.23lab.com
背景
几年前大批量的团队都在转用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, 有兴趣的童鞋可以自己详细看一下。
