[toc]
结论
每一行代码，都会对应一个commit信息
每个commit都会指向一个或者多个父节点的commit。
merge代码的时候，如果新进来的这行代码，和你原有的这行代码，两个commit信息不同了，那么git就会开始找这俩的关系，
如果commit A 和 B 是父子关系，那么就不会冲突，否则会冲突。和这行代码的内容完全无关
这里的父子关系，指的是祖先关系
【commit点之间不是祖先关系】
这里先声明一下我定义的父子，和兄弟关系：
如果commit A能一直递归的指向另一个 commit B， 那么A和B是父子关系
如果上述不成立，且有一个 commit C，C 既能找到 A 又能找到 B，那么，A 和 B是兄弟关系
用上面的图举个例子， C6和图上所有的其他节点都是父子关系
但是 C3 和 C4、 C5 和 C4，这两对组合是兄弟关系。
也就是说如果你在 C4 的状态，merge C5，那么会冲突。
如果 C4 merge C6 那么不会有冲突。
这可能解释了为什么 merge会创建一个新的merge commit点
常用这个操作的都知道，如果你在 C5 的时候去 merge C4，那么一定会生成一个新的Merge commit点 C6，这个点没有任何代码信息，是一个空的节点，连接了这两个并行的分支。
而这个操作正好让 C6 成为了这两个分支的所有祖先，这也就造成了，不管 C6 之后你怎么搞，出了个 C7 C8 什么的，你取任何一个老的节点去merge C6之后的节点，都不会有任何冲突了。
代码冲突，和这行代码本身内容无关，只和commit 哈希值有关
举一个实际项目的例子
假设说我要做个特性，从主干master单拉了一条分支 zach_branch
由于项目要搞很久，我只有联调完，才能把代码回合到主干
操作zach_branch时，我发现主干有一个很低级的语法错误，所以在我的一个commit里面顺手更正了
但是另一个老哥也发现了主干的这个问题，他也更正了，而且改后的代码和我的一模一样
最后，当我一个月后 pull 主干的时候，同样会有冲突，因为这两个commit点明显不是父子关系
