关于解决git冲突

很久很久之前就想自己写博客，现在开始应该不晚，种一棵树的最佳时间是十年前，其次是现在。

最近在公司因为老是遇到git冲突的问题，自己总结了一篇关于git冲突的wiki，现在搬运过来，希望能帮助一些朋友。

场景：假设现在基于远程分支“origin”，创建了一个叫“mywork”的分支，远程分支上已经有了两个提交。 

现在我们在mywork分支上做了两次修改并且提交。此时有两次提交。同时origin分支上也做了一些修改，并且做了提交，这里假定为两次。此时示意图如下：

现在的话两个分支就叉开了，如果在两个分支上修改了同一地方的代码的话，此合并代码会发生冲突，而解决冲突的方式有两种，下面对两种方式进行分析与对比。

方式一：使用git merge

git merge 会把两个分支的代码进行合并，使结果看起来像一次新的合并提交。

相关操作如下：

git merge master

手动修改冲突的部分

git add 修改的类的路径

git commit -am "fix conflict" 写上注释

git merge master 最后检查下是否merge成功

方式二：使用git rebase

git rebase会把“mywork”分支里的每一个提交取消掉，并且把它们临时保存为布丁，然后把“mywork”分支更新为最新的“origin”分支，最后把保存的这些布丁应用到“mywork”分支上。

相关操作如下：

git checkout mywork

git rebase origin

手动修改冲突部分

git add  修改的类的路径

git rebase --continue    （此时git会继续应用余下的补丁）

当然任何时候都可以使用git rebase --abort来终止rebase行动，此时会回退到rebase开始前的状态。

两种方式的区别：

两种方式的区别主要体现在commit的顺序上。

假设C3提交于8:00AM,C5提交于9:00AM,C4提交于10:00AM，C6提交于11:00AM,

对于使用git merge来合并所看到的commit的顺序（从最近到之前）是：C7 ,C6,C4,C5,C3,C2,C1

对于使用git rebase来合并所看到的commit的顺序（从最近到之前）是：C7 ,C6',C5',C4,C3,C2,C1

 因为C5'、C6'提交只是C5、C6提交的克隆，所以使用git rebase来合并后所看到的commit的顺序（从最近到之前）是：C7 ,C6,C5,C4,C3,C2,C1