[非命令行操作]GitHub中的merge与conflict

此处有3张图，分别为2个branch：master和follower；

这是master！划重点了啊！这个是master里面的文件，和follower没有关系的

这个！这个是follower！看清了！follower里面的文件，master还不认识它呢！

第三张图就是merge之后的文件（会出现在其中一个branch里面，看你选择哪个了）：

各位可以看到被绿色圈起来的“新的核对点”，为什么他只出现了一次呢？

是因为在两个文本中，这个“核对点”是完全一致的，于是GitHub就不再更改位置，

将其作为一个核对点，而将上下文中出现的有所不同 的地方以对比的形式表现出来。

而merge的时候，会把母集（之前不是说一个文件是另一文件的子集嘛）独有的信息merge到子集的文档中去，这时候添加进来的代码前面应该只有‘+’，而不会出现“=============”或者带指针的分割线之类的乱七八糟的东西。

【示例中出现的分割线是之前笔者尝试时候出现的】

GitHub会寻找两个文件中完全一致的文本信息作为核对点，求同存异

以上就是单纯的merge，没有conflict搅局。

这是一个分支中文件为另一个分支的子集的情况，可以看到，我们在一个文件中添加了另一个文件没有的东西。所以可以自动merge，这对计算机来说是非常简单的。

conflict

但是如果两个文件不是成为子集的关系呢？

这时候，系统就会向你求救：

X Can’t automatically merge.

可以说这就非常尴尬了，这怎么办呢？

首先，GitHub不会轻易修改你的任何一份代码，因为手心手背都是肉，GitHub也不知道哪个是你需要的。

GitHub两手一摊：“用户，你看怎么办吧，你给我这两个同等重要但是又互相冲突的【conflict】文档，你想要哪个？我看你就是在为难我胖虎。。。”

我：“emmmm...我改就完了呗！”

方案：删除掉其中一份文档的冲突内容，使得一个文档是另一个文档的子集。

下图为GitHub的甩锅图。

而在最新的GitHub网站上，这些操作都可视化了。

即使你不能merge两个有冲突的文档，但是你还是可以记录下来，以供master与follower互相交流。

系统会提示你：“现在你不能merge文档，但是你可以把merge的请求提交上去呀！到时候人家master分支的所有者看到你的请求，再做定夺。”

我说好。

于是我把新的分支的信息pull request，这样有一天master看到了我的提交信息——

于是，我（follower）和他（master）进行了亲切友好的会谈。