很久很久之前就想自己写博客,现在开始应该不晚,种一棵树的最佳时间是十年前,其次是现在。
最近在公司因为老是遇到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”分支上。
![](https://img-my.csdn.net/uploads/201206/14/1339682915_7495.jpg)
相关操作如下:
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