合并冲突
可是,在实际分支合并的时候,并不是想合并就能合并成功的,有时候可能会遇到代码冲突的问题。
为了演示这问题,创建一个新的分支 dev1
,并切换至目标分支,我们可以使用 git checkout -b dev1
一步完成创建并切换的动作,示例如下:
$ git checkout -b dev1
Switched to a new branch 'dev1'$ git branch
* dev1master
在 dev1
分支下修改 ReadMe
文件,更改文件内容如下,并进行一次提交,如:
$ cat ReadMe
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write bbb for new branch # 将aaa该为bbb$ git add.
$ git commit -m"modify ReadMe"
[dev1 0854245] modify ReadMe1 file changed, 1 insertion(+), 1 deletion(-)
切换至 master
分支,观察 ReadMe
文件内容:
$ git checkout master
Switched to branch'master'$ cat ReadMe
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write aaa for new branch
我们发现,切回来之后,文件内容变成了老的版本,这种现象很正常,我们现在也完全能理解。
此时在 master
分支上,我们对 ReadMe
文件再进行一次修改,并进行提交,如下:
$ git branch
dev1
* master$ vim ReadMe
$ cat ReadMe
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write ccc for new branch$ git add.
$ git commit -m"modify ReadMe"
[master 1c10f6d] modify ReadMe1 file changed, 1 insertion(+), 1 deletion(-)
现在,master
分支和 dev1
分支各自都分别有新的提交,变成了这样:
这种情况下,Git 只能试图把各自的修改合并起来,但这种合并就可能会有冲突,如下所示:
$ git merge dev1
Auto - merging ReadMe
CONFLICT (content): Merge conflict in ReadMe
Automatic merge failed; fix conflicts and then commit the result.$ git status
On branch master
You have unmerged paths.(fix conflicts and run "git commit")(use "git merge --abort" to abort the merge)
Unmerged paths:(use "git add <file>..." to mark resolution)both modified: ReadMe
no changes added to commit (use "git add" and/or "git commit -a")
发现 ReadMe
文件有冲突后,可以直接查看文件内容,要说的是 Git 会用 <<<<<<<
,=======
,>>>>>>>
来标记出不同分支的冲突内容,如下所示:
$ cat ReadMe
hello bit
hello git
hello world
hello version1
hello version2
hello version3
<<<<<<< HEAD
write ccc for new branch
=======
write bbb for new branch
>>>>>>> dev1
此时我们必须要手动调整冲突代码,并需要再次提交修正后的结果!!(再次提交很重要,切勿忘记)
$ cat ReadMe
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write bbb for new branch$ git add.
$ git commit -m"merge ReadMe"
[master 2976afc] merge ReadMe
到这里冲突就解决完成,此时的状态变成了
用带参数的 git log
也可以看到分支的合并情况,具体大家可以自行搜索 git log
的用法:
$ git log --graph --pretty=oneline --abbrev-commit
* 2976afc (HEAD -> master) merge ReadMe
|\
| * c59f4d1 (dev1) modify ReadMe
* | c10f6d0 modify ReadMe
|/
最后,不要忘记 dev1
分支使用完毕后就可以删除了:
$ git branch
* master$ git branch -d dev1
Deleted branch dev1 (was c59f4d1).
分支管理策略
通常合并分支时,如果可能,Git 会采用 Fast forward
模式。还记得如果我们采用 Fast forward
模式之后,形成的合并结果是什么样呢?回顾一下
在这种 Fast forward
模式下,删除分支后,查看分支历史时,会丢掉分支信息,看不出来最新提交到底是从哪个分支过来的。
但在合并时如果发生了冲突,我们还是正常提交解决冲突问题,会再进行一次新的提交,得到的最终状态为:
那么就不是 Fast forward
模式了,这样的好处是,从分支历史上就可以看出分支信息。
例如我们现在已经删除了在合并冲突部分创建的 dev1
分支,但依旧能看到 master
其实是由其他分支合并得来的。
$ git log --graph --pretty=oneline --abbrev-commit
* 2976afc (HEAD -> master) merge ReadMe
|\
| * c59f4d1 modify ReadMe
* | c10f6d0 modify ReadMe
|/
Git 支持我们强制禁用 Fast forward
模式,那么就会在 merge
时生成一个新的 commit
,这样,从分支历史上就可以看出分支信息。
下面我们实战一下 --no-ff
方式的 git merge
。首先,创建新的分支 dev2
,并切换至新的分支:
$ git checkout -b dev2
Switched to a new branch 'dev2'
修改 ReadMe
文件,并提交一个新的 commit
:
$ cat ReadMe
hello bit
hello world
hello git
hello version1
hello version2
hello version3
write bbb for new branch$ git add.
$ git commit -m"modify ReadMe"
[dev2 41b82f7] modify ReadMe1 file changed, 1 insertion(+)
切回 master
分支,开始合并:
$ git checkout master
Switched to branch'master'$ git merge --no-ff -m "merge with --no-ff" dev2
Merge made by the 'recursive' strategy.
ReadMe | 1 +
1 file changed, 1 insertion(+)$ cat ReadMe
hello bit
hello world
hello git
hello version1
hello version2
hello version3
write bbb for new branch
a,b,c,d
请注意 --no-ff
参数,表示禁用 Fast forward
模式。禁用 Fast forward
模式后合并会创建一个新的 commit
,所以加上 -m
参数,把 merge
信息写进去。
合并后,查看分支历史:
$ git log --graph --pretty=oneline --abbrev-commit
* 5bde1b4 (HEAD -> master) merge with --no-ff
|\
| * 41b82f7 (dev2) modify ReadMe
* | c10f6d0 modify ReadMe
|/
可以看到,不使用 Fast forward
模式,merge
后像这样:
所以在合并分支时,加上 --no-ff
参数就可以保留分支信息,合并后的历史有分支,能看出来曾经做过合并,而 fast forward
合并就看不出来曾经做过合并。