一、冲突是如何产生的？

当两个分支修改了同一个文件的同一行时，Git无法自动决定保留哪个版本，就会产生冲突-27。

冲突场景示例
假设有两个分支dev2和master，都修改了A.txt文件的同一行：

dev2分支修改： update by dev2 master分支修改： update by master 当在master分支执行git merge dev2时，Git会提示冲突： Auto-merging A.txt CONFLICT (content): Merge conflict in A.txt Automatic merge failed; fix conflicts and then commit the result.

二、冲突标记解读

Git会在冲突文件中插入特殊标记：

<<<<<<< HEAD
update by master
=======
update by dev2
>>>>>>> dev2
标记 含义
<<<<<<< HEAD 当前分支（HEAD指向的分支）的修改开始
======= 分隔符，上方是当前分支的修改，下方是被合并分支的修改
>>>>>>> dev2 被合并分支的修改结束

三、冲突解决流程

3.1 手动解决冲突

打开冲突文件，找到冲突标记

根据需求决定保留哪个版本，或手动合并两者

删除冲突标记（<<<<<<<、=======、>>>>>>>）

保存文件

3.2 提交解决结果

下载 # 标记冲突已解决 git add A.txt # 提交合并结果 git commit -m "merge dev2 into master: resolve conflict"

3.3 取消合并

git merge -abort

四、图形化查看分支历史

Git提供了强大的可视化工具来查看分支结构：

# 图形化显示提交日志 git log --graph # 更简洁的图形化展示 git log --graph --pretty=oneline --abbrev-commit # 查看所有分支的图形化历史 git log --graph --all

实战输出示例：

commit 8d95a43 (HEAD -> master) merge dev2: resolve conflict commit a1b2c3d (dev2) update by dev2 commit e4f5g6h update by master commit 1234567 initial commit

五、分支合并策略

5.1 Fast-forward合并（快进合并）

当目标分支是源分支的直接祖先时，Git会执行快进合并——只是将指针向前移动，不会创建新的合并提交。

# 默认就是fast-forward git merge feature

5.2 非快进合并

强制创建新的合并提交，保留分支历史。

git merge --no-ff feature

使用场景：希望保留功能分支的完整历史，便于追溯。

5.3 压缩合并（squash）

将多个提交压缩成一个提交。

git merge --squash feature git commit -m "add feature xxx"

使用场景：功能分支提交过多过碎，希望保持主分支历史整洁。

六、冲突预防最佳实践

频繁拉取最新代码：在开始工作前和执行合并前，先git pull

保持分支短命：功能分支不要长期存在，完成就合并删除-27

小步提交：每次提交的改动量不要太大

及时沟通：团队成员之间及时同步开发进度

使用git status：合并前确认工作区是干净的

七、总结

冲突不是Bug，而是Git保护代码完整性的机制。掌握冲突解决技能，是团队协作开发的必备能力。

感谢浏览这篇博客，希望这篇博客对你有所帮助~(^ - ^)~