Logo

菜单

易君召
易君召
发布于 2026-08-02 / 2 阅读
0

Git 多人协作：冲突预防 + 完整冲突解决方案

一、先搞懂：Git 冲突产生根本原因

同一文件【同一代码行区间】，多人同时修改，并且先后提交到同一分支，合并时 Git 无法自动判断保留哪一份代码 → 产生冲突。

不同文件、同一文件不重叠行修改：不会冲突，Git 自动合并。

冲突常见场景：

  1. git merge 合并分支

  2. git pull（内部 = fetch + merge）

  3. git rebase 变基

  4. GitHub/Gitee/GitLab PR/MR 线上合并

二、最佳实践：冲突【预防方案】（优先做，减少冲突）

1. 分支规范（最重要）

推荐标准协作流程 GitFlow / Trunk Based（主干开发）

方案 A：Trunk Based（中小型团队、敏捷，推荐）

  • main/master：受保护分支，禁止直接 push，只能通过 PR/MR 合并

  • 所有人从 main 拉出短生命周期特性分支：feature/xxx、fix/bugxxx

  • 分支不要长期存在！尽量1~3 天内合并回主干

分支存放越久，和主干差异越大，冲突爆炸概率直线上升

方案 B：GitFlow（大型稳定项目、版本发布周期长）

main(生产)、develop(开发主干)、feature、release、hotfix

❌ 禁止陋习：多人共用一条长期不合并的开发分支

2. 日常开发规范

  1. 频繁拉取主干最新代码

bash

# 每天开工前、提交代码前执行
git checkout feature/xxx
git pull origin main

提前在本地解决冲突，不要堆积到线上 PR。

  1. 单次提交粒度小

    一个 commit 只做一件事，不要一次改动几十个文件上千行；大范围修改极易碰撞冲突。

  2. 文件拆分、避免多人争抢同一个大文件

  • 超大配置文件、单体 yaml、常量文件最容易冲突；拆分成多个模块文件

  • 前端：不要所有人同时改同一个 vue 组件

  • Java：避免多人同时修改同一个实体类、同一个 Controller

  1. 约定代码区块所有权（团队约定）

    简单规则：同一功能模块尽量指定主要维护人，减少多人同时修改同一文件。

  2. 禁止多人并行重构公共基础代码

    重构公共类、工具类前，群内同步，错开时间开发。

3. 工具层面自动化防控

  1. PR/MR 开启代码评审，CI 流水线自动编译、单元测试；提前发现合并后代码异常

  2. 主干分支开启保护：禁止强制推送 push -f，禁止直接 push

  3. IDE 插件实时提示远端变更（IDEA、VSCode git 插件）

4. 编码层面小技巧

  • 不要多行空行、不要随意格式化全部代码！

❗全员代码格式化标准必须统一（Prettier、Google Java Format、Spotless）

如果 A 用 Tab、B 用空格；一人保存自动格式化整个文件，每次合并必然全文件冲突！

三、冲突出现后：完整解决流程

前置知识点：冲突标记

打开冲突文件，Git 会自动插入标记

java

运行

<<<<<<< HEAD      // 当前分支本地代码
String oldCode();
=======           // 分割线
String newCode();
>>>>>>> feature/test // 拉取过来的远端代码

处理目标：删除冲突标记 <<<<<< ===== >>>>>>，保留正确代码

⚠️ 不要只删除标记不梳理业务代码！很多人合并完出现逻辑 bug。

场景 1：git pull /git merge 产生冲突（最常用）

bash

# 1. 拉代码触发冲突
git pull origin main

# 输出 Auto-merging xxx.java
# CONFLICT (content): Merge conflict in xxx.java
# Automatic merge failed; fix conflicts and then commit the result.

操作步骤

  1. 查看哪些文件冲突

bash

git status

带有 both modified 就是冲突文件

  1. 两种方式解决冲突

    ✅ 方式 1：IDE 图形化工具（推荐，新手首选）

    IDEA / VSCode 内置 Merge 工具，左右对比，一键选择保留本地 / 远端 / 合并两者代码

  • VSCode：点击文件【Accept Current Change / Accept Incoming Change / Accept Both Changes / Compare Changes】

  • IDEA：弹出 Merge 窗口，可视化对比

✅ 方式 2：手动编辑文件（服务器无图形界面时使用）

打开冲突文件，清理标记，编写最终正确代码

  1. 冲突修复完成，加入暂存区

bash

git add 冲突文件名
# 或者全部 git add .

  1. 完成合并提交

bash

git commit
# 不需要额外写信息，git默认生成合并提交信息

  1. 推送远端

bash

git push

❗ 合并冲突中途想放弃，撤销本次合并

bash

git merge --abort

场景 2：git rebase 变基产生冲突（推荐优先 rebase，提交历史更干净）

很多团队要求：特性分支合并前先 rebase 主干，而不是 merge

bash

git checkout feature/demo
git rebase origin/main
# 出现冲突

rebase 冲突处理流程

  1. 修改冲突文件，解决冲突

  2. 添加到暂存区

bash

git add .

  1. 继续变基

bash

git rebase --continue

rebase 会逐个 commit 依次处理冲突，可能多次出现冲突，重复操作

中途放弃 rebase

git rebase --abort

重要提醒：已经推送到远端公共分支，不要随便执行 rebase + push -f，会导致其他人代码丢失！仅私有分支可使用。

场景 3：线上 PR/MR 冲突（Github/Gitee/GitLab 页面提示无法自动合并）

原因：远端主干在你创建分支后有新提交。

正确做法：本地处理冲突，不要在线上手动编辑！

  1. 拉取主干最新代码

  2. 本地切换特性分支，执行 merge main /rebase main

  3. 在本地解决冲突、提交、推送

  4. 页面自动刷新，冲突消失，即可发起合并

禁止直接网页编辑强行合并，极易产生隐藏逻辑 bug。

四、高频踩坑避坑清单

  1. ❌ 冲突直接无脑选择「全部保留远端」或「全部保留本地」

    会丢代码！一定要逐处看懂两边改动含义。

  2. ❌ 代码格式化引发大规模虚假冲突

    团队统一格式化配置，禁止随意全局格式化文件。

  3. ❌ 公共分支执行 rebase 后强制 push

    git push --force 非常危险，多人协作公共分支慎用，优先使用 --force-with-lease

git push --force-with-lease

  1. ❌ 解决冲突后忘记删除冲突标记

    代码直接编译报错，上线事故源头。

  2. ❌ 分支长期不合并，堆积上千行差异，冲突集中爆发

    对策：小分支、短周期、频繁同步主干。

五、推荐日常标准工作流（直接复制落地）

# 1. 开发前同步主干最新代码
git checkout main
git pull

# 2. 创建/切换特性分支
git checkout feature/order-pay

# 3. 编码、多次本地提交
# ...开发代码...
git add .
git commit -m "实现支付下单逻辑"

# 4. 提交前再次同步主干，提前解决冲突（关键一步）
git fetch origin main
git rebase origin/main

# 如果出现冲突：解决冲突 → git add . → git rebase --continue

# 5. 推送远端特性分支，发起PR
git push origin feature/order-pay

六、扩展：配置可视化合并工具（可选）

如果你习惯命令行，可以配置 git mergetool 快速唤起 IDE 解决冲突

# 示例 IDEA mergetool 配置
git config --global mergetool.idea.cmd 'idea --merge $LOCAL $REMOTE $BASE $MERGED'
# 触发工具
git mergetool

原文链接 https://www.yijunzhao.cn/archives/git-team-collaboration-conflict-prevention-resolution-guide

欢迎访问 小易撩挨踢

https://www.yijunzhao.cn/

Linux 磁盘使用查看与管理完整...
AI Agents & 开源 LL...