【编程初学者】创建自己的开源项目7-基于当前分支，提交归并请求到主分支2-代码冲突（myeclipse+git）

第六章 创建自己的开源项目6-基于当前分支，提交归并请求到主分支（myeclipse+git）

上一章讲到 将远程代码库中的自己分支上的代码，归并到主分支中，主要分为三个大的步骤：

    1.提交归并请求 2.查看代码，解决冲突  3.确认归并请求

上一章讲了 1.提交归并请求。 这一章主要讲第二个步骤 ：2.查看代码并解决冲突。下一章讲3.确认归并请求

首先，讲解导致 “冲突” 的根源。如果只有test一个分支，往master 上归并请求，而master 分支上并没有提交过相同的部分的代码。那么，这只会是一次正常的归并，这样的一次归并，并不会导致冲突。这种情况，直接查看代码，（无代码冲突，确认是正确的需要进行归并到master中的代码），那么直接确认归并请求，完成一次代码归并就好了。

现在我们考虑两种可能出现代码冲突的情况。1.master分支上的 Fibonacci.java中的第38行有修改，然后有人拉取的就是master分支，然后代码也提到master 分支上。此时当我们test分支上也修改了Fibonacci.java中的第38行，此时，当我们归并的时候，会发现，master主分支和test分支都改了同一行代码，到底保留哪一行呢？github是无法进行判断的。于是，抛出 "冲突” ，并不进行自动合并，让提交的人进行代码合并解决完冲突之后，再重新提交代码合并请求。2.第二种和第一种情况的本质是一样的，只不过，代码的来源不同，可能是两个分支都往master分支上归并代码，而两个分支同时修改了一个文件的同一行。解决方法也是一样的。首先拒绝自动归并。等待解决冲突之后，master分支再接收代码归并。

为了讲解方便起见，以第一种出现冲突的情况进行讲解。

注：（如果想要查看如何归并第二种出现冲突的问题，请结合第四章，拉取新分支，并在新分支上修改一个文件的某一行，然后再在test分支上修改同一个文件的同一行。人为造成两个分支代码的冲突，然后分别将各个分支的代码提交到各自的github远程代码库的相应分支上。然后，将两个分支提交归并，依次归并两个分支代码，看看，是可以先归并一个请求，还是两个请求都不能归并。）

一。首先，我们人为造成一次冲突

1.我们当前分支是在test分支上，直接修改Fibonacci.java的第38行，并提交到test分支。（具体操作参考第四章）

2.现在先本地myeclipse的分支切换到master分支上，修改Fibonacci.java的第38行。

我这里遇到了一个问题，就是切换分支之后，报错了。原因是，前几次归并过代码，远程代码仓库，test分支上代码合并到master分支了。然后通过pull动作，下载的到本地的时候，冲突了。因为本地现在主要修改的是test分支。而master分支才是主要标准的代码。所以我把本地test分支的修改过的代码提交到远程仓库的test分支。然后重新下载了master分支和test分支。

具体如何下载项目，还是参考第三章。这里补充一点，下载代码的时候，会提示下载那个分支，两个分支都选择就好了。

现在假定已经切换到master分支了。

然后修改38行，为了不影响代码，这里只是加行注释。 

提交代码到master分支。（参考第四章，相信你已经会了。 ）

然后我们到github远程仓库（https://github.com/ 登陆）看下，两个分支，各自的修改。

先进入项目（老奶年的讲解方式，有点啰嗦） 

然后选择分支，先看master分支，后面test分支一样的看法，可以开两个网页看。当然也可以使用github网站提供的代码比对功能进行对比着看。这里两个分开来看。

按照项目的结构，找到修改文件，点击文件名，进入代码。

代码如下：找到38行，看到我们的修改

然后看test分支的修改：

 这说明，已经修改了同一个文件的同一行代码了。

然后。将test分支往master分支合并。

 具体提交一次归并请求的方式，参考第六章。

创建请求的过程中，出现冲突提示：

代码不能自动合并。但不用担心，你仍然可以创建pull请求。

此时，怎么处理呢？这里最好的方式，是回头修改代码。修改master分支还是test分支呢？一般情况下，大家都会以master分支作为主干分支，大家代码都提交到master分支上。所以，最好的方式，就是先保存好test分支该处的修改到本地。然后pull下master分支的修改，覆盖test分支。然后基于master的最新的改动修改test分支。

我们这里，继续创建归并请求，看下github网站是怎么进行处理的。

创建一次归并请求

额，只能关闭该次请求了。

既然要管理该次请求，为何还要在这费尽口舌呢。

这是因为，刚才我们是通过自己提交代码，知道这次请求是有冲突的。然后我们可能会自己不去提交merge （归并）请求。但实际的使用环境中，很有可能，提交归并（merge pull request）请求的人与通过归并请求的人不是同一个人（会是拥有不同操作权限的账户）。只有负责master分支的人，才可以允许其他的归并请求合并。其他分支的代码的人，只有提交归并请求的权限。正常情况下，会强制大家在出现冲突的时候，先自己解决冲突后再提交。但实际过程中，可能有人误操作，即便有冲突没解决就提交归并请求了。这种情况下就关闭该次归并请求就好了。

当test分支的账户的归并请求被拒绝之后，首先问master分支的账户，为什么拒绝归并。

此时得知，冲突，就回到自己的代码分支本地，解决冲突。

回到myeclipse ，切换到test分支，然后pull代码 

点merge 合并代码。此时会把有冲突的部分都列出来。然后把不要的删掉。因为我们这里的冲突少，而且容易解决。像有一些复杂的冲突，比如同时修改的部分，有相同的代码行。那么可能一个方法出现好多冲突点，非常不好解决。建议，手动解决冲突，最好不要使用merge解决。

解决完冲突后，再重新提交归并。然后就是一次正常的归并请求了。不再老奶奶一样啰嗦了。

下一章讲确认归并请求。