Git冲突的本质

Git冲突不是错误，是它发现两个人改了同一行代码、不知道该听谁的时候停下来问你。学会读冲突标记和解决冲突是 Git 协作的必修课。新手最常见的恐惧是：’我合并了冲突提交了，会不会把别人的代码覆盖？’ 学会下面的方法论你会发现：冲突只是日常协作的一部分，根本不可怕。

第一步：理解冲突标记

冲突的文件会出现特殊标记：

<<<<<<< HEAD
main 分支的代码
=======
feature 分支的代码
>>>>>>> feature-branch

  • <<<<<<< 到 ======= 之间是你当前分支（HEAD）的代码
  • ======= 到 >>>>>>> 之间是要合入分支的代码

你需要决定保留哪些、修改哪些、删除哪些。

第二步：触发一次冲突（练习）

  1. 创建 test-conflict 文件，里面写入 ‘line A’
  2. 提交并推送
  3. 创建分支 feature-X，修改为 ‘line B’
  4. 切回 main，修改为 ‘line C’，提交推送
  5. 在 main 执行 git merge feature-X —— 冲突出现

第三步：解决冲突的两种工具

3.1 命令行解决

  1. 打开冲突文件，手动编辑
  2. 删除冲突标记
  3. 保留你想要的代码
  4. git add 标记为已解决
  5. git commit 完成合并

3.2 VSCode 解决

VSCode 打开冲突文件会显示彩色合并视图，三栏：

  • Incoming——要合入的代码
  • Current——当前分支的代码
  • Result——最终结果

点击 ‘Accept Current’、’Accept Incoming’、’Accept Both’ 按钮即可。适合不熟悉命令行的同学。

第四步：常见合并场景

4.1 保留两边代码

两个人添加了不同函数，直接保留全部，删除标记即可。

4.2 保留你自己的

另一边的改动是错的或不需保留，点击 ‘Accept Current’。

4.3 保留另一边的

自己的改动没必要，点击 ‘Accept Incoming’。

4.4 手动合并

代码需要重构或合并两边的逻辑，手动写新版本。

第五步：放弃合并

如果冲突太复杂想重来：

git merge –abort

回到合并前的状态。或者用 git reset –hard HEAD 回退。

第六步：rebase 高阶用法

rebase 是把’我的提交’接到’别人最新提交’后面，让历史更线性。但比 merge 复杂：

  1. git switch feature-x
  2. git rebase main
  3. 如果有冲突，编辑文件 + git add
  4. git rebase –continue 继续
  5. git rebase –abort 放弃

已推送的分支不要 rebase，会推不动。规则：rebase 自己的本地分支，merge 共享分支。

第七步：交互式rebase（改写历史）

想把最近的 3 个 commit 合并成 1 个？

git rebase -i HEAD~3

弹出编辑器，把后两个改成 ‘squash’，保存。Git 自动合并 commit。适合清理提交历史。

第八步：cherry-pick 选择性合并

另一个分支有个 commit 想要，但不想合并整个分支：

git cherry-pick <commit-hash>

把那个 commit 单独拿过来。可以多次使用挑多个 commit。

第九步：冲突预防

最好的策略是不冲突：

  1. 频繁拉取——每天早上 git pull 一次最新代码
  2. 功能分支短——别在分支上开发一周，PR 越小冲突越少
  3. 模块化——团队成员各负责不同模块文件
  4. 沟通——同一文件改动前群里说一声
  5. CI/CD 自动化测试——冲突后跑测试验证

第十步：实战工具

  • VSCode 内置 Git 工具——图形化解决冲突
  • GitLens 扩展——可视化作者和历史
  • GitHub Desktop——适合纯 GUI 用户
  • Sublime Merge——专业 Git 客户端，速度极快
  • Sourcetree——免费、老牌、功能全面

效率提升

从恐惧冲突到日常处理：

  • 冲突平均解决时间从 30 分钟降到 5 分钟
  • 用 rebase 保持提交历史线性，code review 友好度提升 50%
  • 小批量 PR 比大合并冲突率减少 70%
  • 团队每天节省 10 分钟合并时间

核心心法：冲突是协作常态，工具熟练了就能快刀斩乱麻。