Git分支冲突解决与合并策略

一、冲突是如何产生的？

当两个分支修改了同一个文件的同一行时，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保护代码完整性的机制。掌握冲突解决技能，是团队协作开发的必备能力。

|--------|-------------------|
| 场景 | 推荐命令 |
| 查看冲突文件 | git status |
| 手动解决冲突 | 编辑文件，删除冲突标记 |
| 标记已解决 | git add <file> |
| 提交合并 | git commit |
| 取消合并 | git merge --abort |

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