当前位置：首页 > news >正文

【Git】合并冲突

news 来源：原创 2025/8/23 15:39:44

合并冲突

可是，在实际分支合并的时候，并不是想合并就能合并成功的，有时候可能会遇到代码冲突的问题。

为了演示这问题，创建一个新的分支 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 合并就看不出来曾经做过合并。

合并冲突

分支管理策略

相关文章：