冲突的产生

很多命令都可能出现冲突，但从根本上来讲，都是 merge 和 patch（应用补丁）时产生冲突。
而 rebase 就是重新设置基准，然后应用补丁的过程，所以也会冲突。
git pull 会自动 merge，repo sync 会自动 rebase，所以这两个也会产生冲突。

解决 merge/patch 冲突

git merge <branch> 命令用于合并指定分支到当前分支。

假设某一时刻 master 和 feature1 分支是同步的，文件 a.txt 内容如下：

Git is a distributed version control system.
Creating a new branch is quick.

然后在 feature1 上修改了最后一行并提交了：

Creating a new branch is quick AND simple.

切换到 master 分支，也修改了最后一行并提交了：

Creating a new branch is quick & simple.

现在，master 分支和 feature1 分支各自都分别有新的提交，变成了这样：

这种情况下，Git无法执行“快速合并”（快速合并，就是当 Git 发现某一个分支的修改是基于另一个分支的最后一次提交时，会直接指向当前提交），只能试图把各自的修改合并起来，但这种合并就可能会有冲突：

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

git status 可以告诉我们冲突的文件：

# On branch master
# Your branch is ahead of 'origin/master' by 2 commits.
#
# Unmerged paths:
#   (use "git add/rm <file>..." as appropriate to mark resolution)
#
#       both modified:      a.txt
#
no changes added to commit (use "git add" and/or "git commit -a")

直接查看 a.txt 的内容会发现，Git 已经用 <<<<<<<，=======，>>>>>>> 标记出了不同分支的内容：

Git is a distributed version control system.
<<<<<<< HEAD
Creating a new branch is quick & simple.
=======
Creating a new branch is quick AND simple.
>>>>>>> feature1

这时就需要我们手动修改并提交了，例如保留 master 的修改：

Git is a distributed version control system.
Creating a new branch is quick & simple.

再提交：

$ git add a.txt 
$ git commit -m "conflict fixed"
[master 59bc1cb] conflict fixed

冲突解决。现在，master 分支和 feature1 分支变成了下图所示：

同理，使用 git am <patch> 应用补丁产生冲突时，手动解决然后提交。

rebase 的冲突解决

git rebase 的冲突解决过程，就是解决每个应用补丁冲突的过程。解决完一个补丁应用的冲突后，执行 git add -u 命令标记冲突已解决（也就是把修改内容加入缓存）：

-u 表示把所有已 track 的文件的新的修改加入缓存，但不加入新的文件。

然后执行 git rebase --continue 继续 rebase。有冲突继续就重复这这些步骤，直到 rebase 完成。