如何通过Git实现多人并行修改并解决冲突的协作流程？
- 内容介绍
- 文章标签
- 相关推荐
本文共计1130个文字，预计阅读时间需要5分钟。
简要 冲突不是Git的bug，而是它在提醒你：
git pull 时提示 “CONFLICT (content)” 怎么办
这是最常遇到的场景：你本地改了 src/utils.js，同事刚把同一行也改了并 push 到远程，你执行 git pull origin develop 就会卡住，报类似下面的错误：
Auto-merging src/utils.js CONFLICT (content): Merge conflict in src/utils.js Automatic merge failed; fix conflicts and then commit the result.
这不是失败，是 Git 暂停了流程，等你介入。关键点：
- 只影响你改过的文件，其他文件已自动合并完成
- 不要关终端、不要硬退出，否则会卡在
MERGING状态 - 打开冲突文件，你会看到三段标记：
<<<<<< HEAD（你本地的版本）、=======（分隔线）、>>>>>> origin/develop（远程的版本） - 删掉这三行标记，只保留最终需要的代码逻辑，保存文件
- 运行
git add src/utils.js标记为已解决，再git commit -m "resolve conflict in utils.js"
git merge dev 时出现冲突，但不想保留 merge 提交记录
你切到 main 分支后执行 git merge dev，结果冲突了，又不想多出一个 Merge branch 'dev' 提交——这时候不能直接删提交，而该换用 rebase 流程（仅限你自己的分支）：
- 先确保
dev是你本地创建、没推送到远程的分支（或至少没人基于它继续开发） - 回到
dev分支：git checkout dev - 变基到最新
main：git rebase main，冲突会出现在 rebase 过程中 - 逐个解决冲突文件，每解决一个就
git add <file>，然后git rebase --continue - 完成后切回
main，直接git merge dev就是快进（fast-forward），无额外提交
注意：git rebase 会重写 dev 分支的 commit ID，如果该分支已推送到远程且别人拉过，就别用 —— 否则会引发更混乱的同步问题。
两个人同时改同一个分支（比如都 push 到 feature/login）会覆盖吗
不会覆盖，但 push 会被拒绝。Git 默认不允许非快进式推送（non-fast-forward push）。现象是：
! [rejected] feature/login -> feature/login (non-fast-forward) error: failed to push some refs to 'git@gitee.com:team/proj.git' hint: Updates were rejected because the remote contains work that you do hint: not have locally.
这意味着远程分支比你本地“新”。此时必须先拉取：git pull origin feature/login。如果两人改了同一处，就会触发内容冲突；如果改的是不同文件，就自动合并成功。常见误操作：
- 跳过
pull直接push -f强制覆盖 —— 会丢掉同事的提交，属于高危行为 - 用
git stash暂存后pull再stash pop，但 pop 时也可能冲突，仍需手动处理 - 以为
git commit后就能直接push，忽略了远程可能已有更新
冲突解决后 push 失败，提示 “your branch is behind”
说明你在解决完冲突、commit 之后，又有人往目标分支（比如 develop）push 了新提交。此时你的本地 commit 虽然解决了上一轮冲突，但已不是最新的 develop 头部。应对方式只有两个：
- 再跑一次
git pull origin develop（会再次触发冲突，但范围更小，通常只涉及新增的那几行） - 或者改用
git pull --rebase origin develop，把你的解决冲突提交“重放”到最新develop之上，避免嵌套 merge 提交
这个环节最容易被忽略：很多人 resolve conflict → commit → push，发现失败就懵了。其实 Git 在告诉你，“你刚修好的，现在又过期了”。协作越频繁，这种“二次冲突”越常见，别觉得是自己操作错了。
本文共计1130个文字，预计阅读时间需要5分钟。
简要 冲突不是Git的bug，而是它在提醒你：
git pull 时提示 “CONFLICT (content)” 怎么办
这是最常遇到的场景：你本地改了 src/utils.js，同事刚把同一行也改了并 push 到远程，你执行 git pull origin develop 就会卡住，报类似下面的错误：
Auto-merging src/utils.js CONFLICT (content): Merge conflict in src/utils.js Automatic merge failed; fix conflicts and then commit the result.
这不是失败，是 Git 暂停了流程，等你介入。关键点：
- 只影响你改过的文件，其他文件已自动合并完成
- 不要关终端、不要硬退出，否则会卡在
MERGING状态 - 打开冲突文件，你会看到三段标记：
<<<<<< HEAD（你本地的版本）、=======（分隔线）、>>>>>> origin/develop（远程的版本） - 删掉这三行标记，只保留最终需要的代码逻辑，保存文件
- 运行
git add src/utils.js标记为已解决，再git commit -m "resolve conflict in utils.js"
git merge dev 时出现冲突，但不想保留 merge 提交记录
你切到 main 分支后执行 git merge dev，结果冲突了，又不想多出一个 Merge branch 'dev' 提交——这时候不能直接删提交，而该换用 rebase 流程（仅限你自己的分支）：
- 先确保
dev是你本地创建、没推送到远程的分支（或至少没人基于它继续开发） - 回到
dev分支：git checkout dev - 变基到最新
main：git rebase main，冲突会出现在 rebase 过程中 - 逐个解决冲突文件，每解决一个就
git add <file>，然后git rebase --continue - 完成后切回
main，直接git merge dev就是快进（fast-forward），无额外提交
注意：git rebase 会重写 dev 分支的 commit ID，如果该分支已推送到远程且别人拉过，就别用 —— 否则会引发更混乱的同步问题。
两个人同时改同一个分支（比如都 push 到 feature/login）会覆盖吗
不会覆盖，但 push 会被拒绝。Git 默认不允许非快进式推送（non-fast-forward push）。现象是：
! [rejected] feature/login -> feature/login (non-fast-forward) error: failed to push some refs to 'git@gitee.com:team/proj.git' hint: Updates were rejected because the remote contains work that you do hint: not have locally.
这意味着远程分支比你本地“新”。此时必须先拉取：git pull origin feature/login。如果两人改了同一处，就会触发内容冲突；如果改的是不同文件，就自动合并成功。常见误操作：
- 跳过
pull直接push -f强制覆盖 —— 会丢掉同事的提交，属于高危行为 - 用
git stash暂存后pull再stash pop，但 pop 时也可能冲突，仍需手动处理 - 以为
git commit后就能直接push，忽略了远程可能已有更新
冲突解决后 push 失败，提示 “your branch is behind”
说明你在解决完冲突、commit 之后，又有人往目标分支（比如 develop）push 了新提交。此时你的本地 commit 虽然解决了上一轮冲突，但已不是最新的 develop 头部。应对方式只有两个：
- 再跑一次
git pull origin develop（会再次触发冲突，但范围更小，通常只涉及新增的那几行） - 或者改用
git pull --rebase origin develop，把你的解决冲突提交“重放”到最新develop之上，避免嵌套 merge 提交
这个环节最容易被忽略：很多人 resolve conflict → commit → push，发现失败就懵了。其实 Git 在告诉你，“你刚修好的，现在又过期了”。协作越频繁，这种“二次冲突”越常见，别觉得是自己操作错了。