导言

Git 冲突的本质是并行开发中代码变更的重叠与未及时同步，而非单纯的技术问题。

一、先搞懂：Git 冲突的 3 大核心根源

在解决问题前，必须明确冲突的来源，才能针对性预防：

同步滞后：长期在本地分支开发，不与主分支同步，导致累积大量差异（最常见，占冲突总量的 60%+）

范围重叠：多开发者同时修改同一文件的同一代码块（如两个开发者改同一个接口的参数）

管控缺失：无分支规范（如直接在主分支开发）、无提交标准（大提交包含多个功能）、无依赖锁定（package.json 频繁冲突）

二、核心策略 ：搭建「零冲突友好型」分支体系

分支管理是冲突规避的基石，90% 的高频冲突源于混乱的分支结构。推荐两种经过验证的分支模型，团队需二选一并严格执行。

2.1 选择适配的分支模型

根据团队规模和项目类型选择，避免混合使用导致混乱：

分支模型 适用场景 核心分支结构 冲突风险
Git Flow 中大型项目、有固定发版周期 main (生产)+develop (开发)+feature/bugfix/hotfix 低
GitHub Flow 小型项目、敏捷迭代（如 ToB 产品） main (主分支)+feature/bugfix (临时分支) 极低

关键规则（必须落地）：

  • 禁止直接在main/develop分支提交代码，所有开发必须基于「临时分支」

  • 临时分支必须从「最新主分支」创建（如 feature 分支从 develop/main 最新版创建）

  • 分支命名强制规范，一眼识别用途：

    • feature/[需求ID]-功能描述（如feature/TAPD1234-用户登录加密）
    • bugfix/[缺陷ID]-问题描述（如bugfix/JIRA567-登录超时异常）
    • hotfix/[紧急ID]-修复描述（如hotfix/EMG789-生产支付接口报错）

2.2 分支生命周期管理（避免「僵尸分支」）

  • 创建：需求启动时，由负责人从主分支创建，同步到远程仓库（git push -u origin 分支名）

  • 开发：仅负责对应需求，不包含无关修改（如改登录功能时不碰商品模块代码）

  • 合并：需求上线 / 修复验证后，48 小时内完成合并并删除分支（避免分支堆积）

  • 归档：重要分支（如发版分支release/v1.2.0）需归档，其他临时分支合并后立即删除

三、核心策略 2：原子提交 + 实时同步，消灭「累积冲突」

同步滞后是冲突的第一杀手，通过「小步提交 + 高频同步」可解决 80% 的此类问题。

3.1 原子提交规范（每个提交只做一件事）

  • 提交粒度：每完成一个独立逻辑（如「添加登录参数校验」「修复密码错误提示」）就提交，原则上每 2 小时至少 1 次提交（符合 Rules 基本原则）

  • 提交操作：用git add -p精确选择变更代码，避免「一次性提交所有修改」（防止无关代码混入）

  • Commit Message 规范（禁止无头提交）：采用「Conventional Commits」格式，示例：

    • feat(login): 添加用户密码MD5加密存储（功能新增）
    • fix(pay): 修复支付宝回调参数解析异常（bug 修复）
    • docs: 更新API文档中登录接口说明（文档修改）

3.2 实时同步主分支（关键操作，每天必做）

  • 核心逻辑：让你的 feature 分支始终跟主分支保持一致，避免差异累积。

  • 具体步骤（每天早开工 / 午开工各 1 次）：

1
2
3
4
5
6
7
8
9
10
11
12
13
# 保存本地未提交的工作（避免同步时丢失）
git stash save "未完成的[功能名]开发"  # 示例：git stash save "未完成的登录加密开发"

# 2. 拉取主分支最新代码（假设主分支是main）
git checkout main
git pull origin main

# 3. 切回自己的feature分支，用rebase同步主分支（避免产生无用的合并记录）
git checkout feature/TAPD1234-用户登录加密
git rebase main

# 4. 恢复本地未提交的工作
git stash apply  # 若有冲突，此时会提示，解决后再继续开发

⚠️ 关键提醒：如果 rebase 过程中出现冲突，必须在当前步骤解决，不能跳过（符合 Rules「拒绝忽略冲突」原则）。解决后执行git rebase --continue，直到 rebase 完成。

四、核心策略 3：协作沟通 + PR 审查，提前阻断冲突

很多冲突是「沟通缺失」导致的，比如两个开发者同时改同一文件 —— 通过「前置沟通 + 代码审查」可完全规避。

4.1 变更前沟通机制（5 分钟沟通 = 1 小时解决冲突）

  • 任务认领：在需求管理工具（Jira/TAPD）上明确「代码修改范围」，比如标注「需修改文件：src/login/index.js」，避免多人重复修改

  • 跨模块协作：若修改涉及公共代码（如工具函数、公共组件），必须提前在团队群同步，确认无其他人在修改

  • 临时变更：紧急修改（如临时加日志）需告知相关开发者，避免对方同步代码时冲突

4.2 PR（Pull Request）审查闭环（禁止无审查合并）

PR 是冲突的「最后一道防线」，必须满足以下条件才能合并：

基础检查：

  • 分支来源正确（必须从最新主分支创建）

  • 无冲突（PR 页面显示「Can be merged」）

  • 提交记录清晰（无冗余提交，Commit Message 规范）

代码审查要点：

  • 审查者需确认「修改范围是否与需求一致」（避免无关修改）

  • 检查「是否修改了公共代码」（若有，需确认是否影响其他模块）

  • 验证「单元测试是否通过」（避免引入新 bug）

合并策略：

  • 优先用「Squash and Merge」（将多个提交压缩为 1 个，保持主分支整洁）

  • 禁止用「Merge Commit」（会产生大量合并记录，不利于版本追溯）

五、应急处理：冲突发生后的 SOP（10 分钟内解决）

即使做好预防，仍可能出现冲突，需按以下步骤处理，避免混乱：

步骤 1：隔离冲突，不影响他人

1
2
3
4
5
# 若正在开发中，先保存本地工作
git stash save "冲突前的工作状态"

# 2. 查看冲突文件（红色标记的文件即为冲突文件）
git status

步骤 2：分步解决冲突

打开冲突文件：找到<<<<<<< HEAD（你的代码）、=======（主分支代码）、>>>>>>> 分支名（冲突分支代码）标记

协商解决：若不确定如何修改，立即找到修改该文件的开发者，共同确认保留哪部分代码（禁止独自删除他人代码）

删除冲突标记：解决后必须删除<<<<<<</=======/>>>>>>> ，避免代码报错

验证：执行git add 冲突文件，然后运行测试（如npm run test），确保解决后功能正常

步骤 3：无法解决时的回滚方案

若冲突复杂（如大量代码重叠），可放弃当前同步，回到之前的状态：

1
2
3
4
5
# 终止rebase过程，回到rebase前的状态
git rebase --abort

# 或直接回滚到上一个稳定版本（需确保已stash本地工作）
git reset --hard HEAD~1  # 回滚到上一个提交

⚠️ 风险提示：git reset --hard会丢弃未提交的修改，执行前必须确认已用git stash保存工作。

六、落地保障：让方案真正执行

团队培训：新成员入职必须培训 Git 规范，老成员每季度进行 1 次 Git 复盘

指标监控：每周统计「冲突次数」「PR 合并时长」，作为团队协作效率的 KPI

奖惩机制：对严格遵守规范的成员公开表扬，对多次违反规范（如直接在主分支提交）的成员进行辅导