[非命令行操作]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)进行了亲切友好的会谈。

 

你可能感兴趣的:(GitHub,GitHub,新手教程)