Git 冲突处理

冲突出现原因：假设当前有分支master和分支dev，开始它们是从同一个节点开始的，以下是他们的操作记录。

1. master修改了a文件,添加了文字"master"，并提交到master
2. dev修改了a文件，添加了文字"dev"，并提交到dev

此时，master想要合并dev，但是git发现master和dev都对a文件进行了修改，git不知道到底是该以master为标准，还是以dev为标准，又或者是其他，只能告诉你出现了冲突

>$git merge dev
Auto-merging test.txt
CONFLICT (content): Merge conflict in test.txt
Automatic merge failed; fix conflicts and then commit the result.

打开发生冲突的文件

//以下为文件出现冲突的部分
<<<<<<< HEAD
sss
=======
lll
>>>>>>> dev

<<<<<<< HEAD到=======表示当前分支在这个文件更改，=======到>>>>>>> dev为dev分支的更改。

你可以选择删除这三处地方，并且留下你想要的修改，然后提交，也可以选择使用git merge --abort来取消这次合并。

注意，修复冲突后直接提交必定会产生一个新的commit，即为修复冲突的那个commit，可以使用rebase解决这个问题

关于使用git pull还是使用git fetch + git merge | git rebase的解析

1. git pull将远端内容直接拉取到本地，并且自动进行快速合并，优点：快速，在明确知道不会有冲突的情况下极其好用，缺点：不安全，可能会产生冲突，并且修复后会产生修复冲突的节点
2. git fetch将远端内容拉取到本地，但不会直接合并，优点：安全，缺点：繁琐，需要使用git merge或者git rebase进行合并

解析git merge和git rebase不同

1. git merge将分支1和分支2的更改进行组合，并产生一个新的commit，该commit包含两个分支所有的更改
2. git rebase先取消掉分支2与分支1从最后一个都有的节点开始的所有的提交，然后使用快速合并将分支1合并到分支2，此时分支2的HEAD指向分支1最后一个提交，然后再将被取消掉的分支2的更改添加上去，这样便形成了一个看上去似乎就像是先写了分支1的内容，再写了分支2的内容，而没有合并过的样子。

演示git fetch+git rebase^[1]

//加了中括号将会在本地新创一个分支，并将远端内容放入
git fetch <remoteRepName> <branchName>[:<newBranchName>]
-----
>$git fetch origin master
From xxx
* branch            master     -> FETCH_HEAD
>$git diff FETCH_HEAD
diff --git a/test.txt b/test.txt
index 7845909..506ee1c 100644
--- a/test.txt
+++ b/test.txt
@@ -2,4 +2,4 @@
...
-sss
+lll ^M
>$git rebase FETCH_HEAD
...
.git/rebase-apply/patch:9: trailing whitespace.
lll
warning: 1 line adds whitespace errors.
error: Failed to merge in the changes.
Using index info to reconstruct a base tree...
M       test.txt
Falling back to patching base and 3-way merge...
Auto-merging test.txt
CONFLICT (content): Merge conflict in test.txt
Patch failed at 0001 12
The copy of the patch that failed is found in: .git/rebase-apply/patch
...

---修复冲突后

>$git add --all
>$git rebase --continue
Applying: 12