eclipse git处理冲突

一.模仿冲突和解决

我们模仿下冲突：

首先在github建个仓库，随便上传个项目，克隆到本地，用eclipse导入。

项目报错不管，不妨碍我们

1.在github 修改pom文件，加一行内容,提交。

2.在eclipse修改pom文件，也加一行内容

3.这时候，打开Synchronize,尝试在eclipse 加入index，然后提交 commit and push 。

提交失败，因为更改了同一个文件

4. 第三步我们尝试的是提交失败，其实如果在更改pom文件后，因为更改了同一个文件，这时候pull 拉取也是同样失败的，

一样被拒绝。 后续处理冲突的操作是一样的。

5.失败后，我们先将文件提交到本地，就是commit操作，而不是commit and push操作。

6.commit之后，再pull 就可以成功了，如果没有提交到本地，pull是失败的

可以看到pull成功，pom文件上有红色冲突标记，文件中出现了

<<<<<<< HEAD 和=======之间的是本地文件冲突的内容

======= 和>>>>>>> branch 'master' of https://github.com/MeloFocus/TestGit.git 仓库中冲突文件的内容

7.修改冲突。

可以直接在pom文件中 修改，比如吧head>>>>这些删除掉，变成自己要的。

也可以通过对比工具，Merge tool

跟svn一样可以对比，把远程文件内容点击添加到本地文件，右上角有工具可以使用

8.编辑成想要的样子后，将文件冲突标记为已解决

9.点击标记已解决后，在git staging自动会将文件加入index，并且设置好提交的日志，“合并什么冲突......”

10.commit and push 就成功了

再看文件，没有冲突了

二.其他实验

1.当 eclipse更改和新加文件，在github也添加新文件和更改，如果更改文件与eclipse 是不同的文件时，不会有冲突，在eclipse端一直pull都是成功的

2.sts更改一个apple.java commit，github也更改apple，同时新增B.java文件，因为github更改是直接在仓库更改，立刻生效，sts更新时，会报apple冲突这是肯定的，但同时在冲突那栏底下放着B.java，并且B.java已经被放在了staged changes上，也就是B.java已经被加入index，等待被commit。commit后B.java的冲突也不见了，变为正常标识

当解决完apple的冲突后，必须同时commitB.java 然后更新 推送就好了。 这也是为什么总发现自己要提交很多自己没更改过的文件。

应该这么解释，刚开始更改apple commit是提交到本地仓库了，而pull下来的新apple 和B.java 是更新到本地了，解决冲突后commit 是提交本地仓库，本地仓库与本地代码对比并没有B.java，所以理应提交B和apple。然后再统一推送。  git工具能识别到B.java不是你改的，是新拉下来的文件，所以自动加入index，等待你commit。

推送后，看github的日志，B.java的日志是github提交时写的，跟sts无关；而apple的日志是sts 解决冲突。

3.实验，原文件有apple.java,B.java,Cat.java,D.java

在github上，删除D.java,更改apple，更改B.java，新增E.java.

在sts更改apple。

在sts commit apple后，再pull。 发现apple冲突肯定的。

显示对E D B三个文件 都已加入index，E文件是新增标志，D是删除标志，B是修改标志。这点跟上述第2实验的原因是一样的。三个文件是从远程仓库pull到本地代码的，在pull前本地代码commit过一次，本地代码跟本地仓库对比后，三个文件的状态就是这样。

解决apple的冲突后，apple自动加入index。提交信息写着解决apple冲突，没有对E D B文件的操作

推送日志也写得两条，sts端对apple文件的操作，没有对 D B E的操作，符合逻辑

github的日志也一样。

4. 在gitub 对文件增删改查，在sts 对文件修改，只要sts动过的文件和github动过的文件没有相同的，在sts端更新时就不会冲突，并且pull后，会直接同步到本地仓库，不会把github端动过的文件放在index，像第3点那样 sts还要commit到本地仓库。