两个技术人员各负责一个功能板块的开发，提交的时候发现项目原本的一个代码文件，两个人都有修改，起冲突了，请问应该如何处理？

这是Git多人协作中的正常保护机制，完全不用慌。本质是Git检测到同一文件的同一处代码被两个人同时修改，无法自动判断该保留哪个版本，于是暂停合并，等待人工决策。处理的核心是「明确双方修改意图→人工敲定最终版本→验证后提交」，全程有标准流程可依。

下面给你可直接落地的处理方案、避坑原则，以及从根源减少冲突的协作规范，非常适合两人分工开发的小团队。

一、标准冲突解决流程（可直接照着做）

假设场景：同事A先把代码推送到了远程仓库；同事B本地也修改了同一文件，执行git pull拉取最新代码时触发冲突。以下是完整处理步骤：

步骤1：先保证本地代码安全

如果你的本地代码还没写完、不想提交，先临时暂存起来，避免拉取时丢失修改：

git stash  # 把本地未提交的修改临时暂存
git pull   # 拉取远程最新代码
git stash pop # 把暂存的修改放回来，此时会正式触发冲突

如果代码已经写完提交了，直接执行git pull即可，Git会自动进入合并冲突状态。

步骤2：定位冲突文件

执行git status，会看到标注为both modified的文件，就是存在冲突的文件。

git status
# 输出示例：
# 未合并的路径：
#   （双方修改）  src/utils/request.js

步骤3：看懂冲突标记，人工决策最终代码

打开冲突文件，Git会用固定格式标出冲突区域：

<<<<<<< HEAD  
// 上方是你本地当前分支的代码（你的修改）
function request() {
  // 你新增的超时配置
  timeout: 10000
}
=======
// 下方是远程拉取的代码（同事的修改）
function request() {
  // 同事新增的请求拦截配置
  interceptors: [...]
}
>>>>>>> origin/dev

• <<<<<<< HEAD：冲突开始标记，上方是你本地的代码
• =======：分隔线，上下是两个不同的修改版本
• >>>>>>> origin/dev：冲突结束标记，下方是远程/同事的代码

步骤4：编辑文件，解决冲突

根据业务需求，删掉不需要的代码、保留最终版本，然后把三行冲突标记（<<<<<<<、=======、>>>>>>>）全部删除。

工具快捷操作：用VS Code打开冲突文件，会在冲突区域上方显示4个按钮，点击即可快速处理：
- 接受当前更改：只保留你本地的代码
- 接受传入更改：只保留同事的远程代码
- 接受双方更改：两边代码都保留，自动合并
- 比较更改：左右对比两个版本的差异

步骤5：本地验证，确认无误

这一步绝对不能省：冲突解决完先运行项目，确认功能正常、没有语法报错。
可以全局搜索一下文件，确保没有遗留<<<<<<<、=======这类冲突标记，否则会直接导致代码语法错误。

步骤6：提交合并结果，推送到远程

验证通过后，重新提交代码并推送，冲突就彻底解决了。

git add src/utils/request.js  # 标记冲突文件已解决
git commit -m "fix: 解决request.js冲突，整合超时配置与拦截器逻辑"
git push

二、4种常见冲突场景的处理方式

实际开发中，根据两个修改的业务关系，通常有4种处理选择：

| 场景 | 处理方式 | 典型例子 |
| :--- | :--- | :--- |
| 两个修改都是有效功能，互不冲突 | 两边代码都保留，合理整合顺序 | 你加了登录接口，同事加了注册接口，都保留即可 |
| 你的修改更完善，对方的版本过时了 | 保留你的代码，放弃对方的 | 你重构了整个工具函数，同事只是改了小参数，以重构版为准 |
| 对方的修改是最终需求，你的改重复了 | 保留对方代码，放弃自己的 | 产品已经让同事改了这个逻辑，你不知情也改了，直接用同事的版本 |
| 两边都有问题，单独放一起跑不通 | 融合改写，结合两边的逻辑重写 | 你改了A逻辑，同事改了B逻辑，但两者有依赖，需要整合重写 |

三、解决冲突的核心原则（避免踩大坑）

很多团队解决冲突反而引出更大问题，基本都是违反了以下原则：

1. 绝对不擅自删除他人代码

看不懂对方的修改、不知道为什么改，就直接找对方沟通确认，不要凭感觉删掉。删错功能、丢逻辑是冲突处理最常见的事故。

1. 解决完必须本地测试

不要改完直接提交，哪怕只是改了几行代码，也至少跑一下项目、验证两个功能都正常。带着语法错误、逻辑bug提交，会拖累所有人的开发节奏。

1. 禁止强制推送（git push -f）覆盖公共分支

冲突解决不了就强行覆盖远程代码，会直接抹掉同事的提交历史，造成代码丢失。这是多人协作的大忌，仅允许在自己的私有功能分支上使用。

1. 提交备注写清楚处理内容

备注里说明冲突的文件、整合了什么内容，方便后续排查问题时追溯，比如“解决配置文件冲突，保留A的路由配置+B的环境变量”。

四、从根源减少冲突的协作规范（长期治本）

两个人各负责一个功能板块，理论上应该尽量各改各的文件，频繁冲突往往是分工和协作习惯有优化空间。做好以下5点，能减少80%以上的无意义冲突：

1. 文件拆分：模块隔离，减少公共文件修改

• 按功能模块拆分文件，每个功能对应独立的文件/文件夹，尽量避免所有人都往同一个大文件里写代码。
• 公共文件（如配置文件、工具函数、主入口）尽量保持稳定，必须修改时提前和另一个人打招呼，避免同时修改。

2. 开发节奏：小步提交，频繁同步

• 不要攒一大堆代码再提交推送，拆成小功能点，完成一个提交一个，每天至少拉取1~2次远程最新代码。
• 冲突范围越小越好解决：改10行代码的冲突1分钟就能处理完，改几百行的冲突可能要花半小时，还容易出错。

3. 分支规范：功能分支隔离，合并前先解决冲突

推荐最简单的分支模式，非常适合2~3人小团队：

• 保留main主分支（线上稳定版本）和dev开发分支；
• 每个人开发新功能时，从dev新建独立的功能分支（如feature/login、feature/pay），在自己分支上开发；
• 功能做完后，先把dev的最新代码拉到自己的功能分支，在本地解决完所有冲突、测试通过，再合并到dev分支。

这样冲突永远在个人分支解决，不会污染公共开发分支。

4. 事前对齐：公共修改提前沟通

开发前简单同步一下：“我要改request.js这个公共工具类，加个错误上报”，对方就可以避开同期修改，或者等你提交后再基于新版本开发。
越是公共的底层文件，越要提前同步，避免两个人各自大改，最后出现大面积冲突。

5. 格式统一：消除无意义冲突

统一代码格式化规则（比如用Prettier），所有人保存代码时自动格式化。避免因为空格、换行、缩进、单双引号这类格式差异，产生大量毫无业务价值的冲突。

总结

代码冲突不是“麻烦”，而是Git的安全机制——它强制你关注他人的修改，避免悄无声息覆盖对方的代码，反而保障了协作的安全性。
短期解决按「定位→决策→验证→提交」四步走，长期通过模块拆分、小步提交、分支规范优化，两人协作的冲突会非常少，即使出现也能快速处理。