🌿 Git 与版本控制站

Appearance

06 · merge 与冲突处理 ​

记忆锚点：冲突不可怕，它是 Git 在说「两个分支都动了同一行，你替我决定留下哪个」。

一、merge 的两种结局 ​

把 dev 合进 main：先 git switch main，再 git merge dev。结果只有两种：

1. 快进（fast-forward）：main 自分叉点后没动过，Git 只是把 main 指针往前挪到 dev 的位置——没有任何新提交产生，历史是一条直线。

2. 真合并：两边都有新提交，Git 找共同祖先，做一次三方合并，生成一个有两个父提交的合并提交，历史出现分叉再汇合的形状。

bash
git switch main
git merge dev
# Fast-forward 提示 → 快进
# Merge made by the 'ort' strategy → 真合并
git log --oneline --graph --all   # 看形状

二、冲突长什么样 ​

两个分支改了同一个文件的同一处，Git 拿不准就用冲突标记把两个版本都摆出来：

<<<<<<< HEAD
main 分支上的写法
=======
dev 分支上的写法
>>>>>>> dev

此时 git status 会把文件标成 both modified。注意：冲突只发生在工作区，仓库历史没有任何损坏——修好之前别急着提交而已。

三、解决冲突三步 ​

bash
# 1. 打开冲突文件，把 <<<<<<<、=======、>>>>>>> 之间改成的你想要的最终版本
#    （可以留一边、融合两边、或全部重写——决定权在你）

# 2. 标记冲突已解决（把修好的版本放进候选名单）
git add 解决完的文件

# 3. 全部解决后，完成合并提交
git commit            # Git 已备好默认信息，确认即可

中途想放弃？git merge --abort 一键回到合并前的状态，干干净净。

四、减少冲突的习惯 ​

  • 小步快合：分支存活时间越短，共同祖先越近，冲突面越小；
  • 一个分支一个主题：和第二章「提交粒度」一脉相承；
  • 勤 pull 勤同步：让本地与主线差距保持很小；
  • 真冲突了也不慌：冲突标记里挑版本是体力活，不是技术难题。

五、动手实验 ​

  1. 建分支 dev，两个分支分别改 f.txt 的同一行为不同内容；
  2. 在 main 上 git merge dev，亲眼看一次冲突标记；
  3. 融合两边文字，git add + git commit 完成合并；
  4. git log --oneline --graph --all 欣赏这次分叉与汇合；
  5. 再造一次冲突，用 git merge --abort 体验一键反悔。

六、本课小结 ​

  • merge 两结局：快进（挪指针）与真合并（双父提交）；
  • 冲突 = 同行分歧，标记区里人肉裁决，add → commit 收尾；
  • --abort 随时撤，小分支勤合并是最好的预防。

下一篇：rebase：改写历史的规则