小楚这几天心情很不好……
这不前几天领导给安排了任务，小楚经过几天辛苦的开发以及测试之后，一切顺利，准备上线。上线之前，领导告诉他有个临时性的功能刚上线，所以让他合并一下最新分支，以免丢失了那部分代码。于是，小楚就把主分支的代码合并到了自己的分支。合并很顺利，没有冲突。小楚想着不用再测了，因为小楚觉得没有冲突就意味着我没有改他们提交的那部分代码而他们也没有改我提交的那部分代码，所以没有问题可以上线。
可是小楚刚上线没多久，领导就找了过来，说线上有问题，问他怎么回事儿，让他赶紧找原因。小楚心想不可能啊，测试没问题啊。测试通过之后，自己也没改过代码，只是合并了一下主分支而已。合并的时候没有冲突，意味着没有别人改过自己的那部分代码。但问题的确在，并且问题应该就出现在代码逻辑部分。小楚打开代码，认真看了下，竟然发现自己改的那部分代码所在的文件其他部分多了一行代码。问题就是因为这一行代码引起的，经过讨论后，小楚把这行代码删掉。紧急测试后，又紧急上线，才终于解决了线上的问题。
线上的问题虽然解决了，但是小楚心中的疑惑还没解开。出问题的这行代码到底从哪儿来的呢？应该是合并代码的时候出来的。但是为什么没有报冲突呢？带着这些疑问，小楚找到了自己的好朋友大高。
大高听小楚讲完，只说了一句话，想知道为什么，看代码就行了。擦，穿越了，不是这句话，而是你知道git merge是如何判断冲突的吗？
小楚说，同一个文件，两个分支不一样合并的时候就会冲突。
大高听小楚这么说，就笑道，你一定没真正思考过这个问题吧，只是知道不一样就会冲突！具体是什么不一样，却没仔细思考和研究。是文件吗？如果是的话，你想想两个分支的同一个文件不一样这不是必然的吗？如果一样的话就不需要合并了啊！不一样是一定的，但不一样不意味着一定冲突。
大高讲到兴起，也不管小楚听不听得懂，就一直讲起来。
合并冲突是指如果你在两个不同的分支中，对同一个文件的同一个部分进行了不同的修改，Git 没法干净的合并它们，于是在合并它们的时候就会产生合并冲突。这个定义有两层含义，一层是两个分支都对同一个文件做了修改；另一层是两个分支对同一个文件的相同部分做了不同的修改。首先如何判断对文件做了修改？我们按照git官方的叫法，称当前分支ours，将要合并进来的分支叫theirs。theirs分支比较好判断，只要拿我们刚check出来时候的版本跟我们现在的版本进行比较就可以。假设我们刚check出来的时候文件是3行，每行分别是1、2、3。我们当前文件是4行，每行分别是1、4、2、3。这就说明我们对文件做了修改，并且可以列出我们修改的内容:在1和2之间插入一行4。ours分支怎么判断呢？因为，现在ours分支是master分支总不能从第一次提交来判断吧？暂时想不到，我们就把问题放一放，先看第二层。如何判断两个分支对同一个文件的相同部分做了不同修改。我们最终目的是判断不同，所以首先得确定相同。所以这里的同一个文件应该也有两层含义，第一层是同一个目录下的同名文件；第二层含义是这个文件的版本是一样的。这个确定的版本的文件其实就是第三方，而git用的就是三方合并。确定了第三方，我们回过头来看。我们已经知道了theirs分支的情况，现在来看ours分支。文件当前内容是也4行，每行分别是1、2、3、6。那我们的第三方进行比较，得出结论，ours分支对文件做了修改，修改内容是:增加了6这一行。所以当我们合并分支的时候，因为是对不同部分做了修改，结果会是1、4、2、3、6。并不会冲突。
现在你知道为啥你的代码里会多出一行了吗？大高讲完，问小楚。小楚回答道原来是这样，我知道了。但还有个问题，那如何判断是不是对相同部分做了不同修改呢？这个就要用到diff3算法，有兴趣的话，可以去找资料看下。说完，大高拍拍衣袖，转身离去。