完成双人协作并解决冲突
现在有两个工作副本：小林维护 team-task-board，小周维护 bob-workspace。两人都从同一个提交出发，并且都会修改 tasks.md 第一行。这正好能看清冲突为何发生、Git 能做什么、最终决定应由谁来做。
小周先完成修改并推送
进入小周的工作副本：
bash
cd ../bob-workspace把 tasks.md 第一行从：
text
负责人：待分配改成：
text
负责人：小周检查、提交、推送：
bash
git diff -- tasks.md
git add tasks.md
git commit -m "docs: assign task owner to Xiaozhou"
git push origin main远程 main 现在包含小周的提交，而小林的工作副本还不知道这次更新。
小林基于旧版本提交
切回原项目：
bash
cd ../team-task-board把同一行改成：
text
负责人：小林然后提交，但先不推送：
bash
git add tasks.md
git commit -m "docs: assign task owner to Xiaolin"这条提交本身完全合法。冲突不是“谁提交错了”，而是两条分支对同一处内容给出了不同结果，Git 无法替团队决定最终文字。
先获取，再主动合并
先更新远程跟踪分支：
bash
git fetch origin结果示例：
text
From .../remote/task-board
05dc2c4..5d11334 main -> origin/main此时工作文件还保持小林的版本。可以先比较两边：
bash
git log --oneline --left-right main...origin/main
git diff main..origin/main -- tasks.md确认后再合并：
bash
git merge origin/main结果：
text
Auto-merging tasks.md
CONFLICT (content): Merge conflict in tasks.md
Automatic merge failed; fix conflicts and then commit the result.退出状态非零表示合并暂停，等待解决。查看状态：
bash
git status --short结果：
text
UU tasks.md两个 U 表示双方都修改了这个路径，尚未解决。
读懂并消除冲突标记
打开 tasks.md，冲突区域会类似这样：
text
<<<<<<< HEAD
负责人：小林
=======
负责人：小周
>>>>>>> origin/main<<<<<<< HEAD到=======是当前分支的内容；=======到>>>>>>> origin/main是正在合入的内容；- 这些标记只是帮助你比较，不能留在最终文件里。
团队决定由两人共同负责，因此把整个冲突块替换成一行：
text
负责人：小林、小周确认已经没有标记：
bash
git diff --check
git grep -n -e '<<<<<<<' -e '=======' -e '>>>>>>>' || true第一条会检查空白问题，第二条会搜索残留标记。没有输出说明检查通过。
把解决后的文件标记为已处理，再完成合并提交：
bash
git add tasks.md
git status --short
git commit -m "merge: resolve task owner conflict"git add 在冲突处理中仍然是“选择最终内容”。Git 看到冲突路径的新版本进入暂存区，就知道这一路径已经解决。
如果发现合并方向错了，或需要先讨论方案，可以在尚未提交合并结果时执行 git merge --abort。它会尝试回到合并开始前的状态。
发布解决结果并同步队友
小林先把合并结果推送到远程：
bash
git push origin main查看提交图：
bash
git log --oneline --graph --decorate -5结果示例：
text
* bc6bde7 (HEAD -> main, origin/main) merge: resolve task owner conflict
|\
| * 5d11334 docs: assign task owner to Xiaozhou
* | a2424eb docs: assign task owner to Xiaolin
|/
* 05dc2c4 merge: add task priorities小周的工作副本可以快进到这个合并结果：
bash
git -C ../bob-workspace pull --ff-only结果：
text
Updating 5d11334..bc6bde7
Fast-forward
tasks.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)--ff-only 表示只接受不需要新合并提交的更新。如果小周还有未发布提交，命令会停下来，不会擅自改写历史。
把协作流程变成习惯
每次开始新工作前，先更新稳定分支，再创建功能分支：
bash
git switch main
git pull --ff-only
git switch -c feature/short-name准备分享时：
bash
git status --short
git log --oneline origin/main..HEAD
git push -u origin feature/short-name这里没有演示平台上的 Pull Request，但命令行部分已经准备好：功能分支被推送后，在平台创建评审请求；评审通过再合并。不要在同一个分支混入格式化、重命名和新功能等无关修改，它们会让评审和冲突处理同时变难。
冲突处理清单
执行 git status 找出所有冲突路径，不要只处理终端最先显示的那个文件。
阅读双方内容和业务意图，编辑出真正需要的最终版本，并删除全部冲突标记。
用 git diff --check、项目测试和必要的搜索验证结果，再对已解决路径执行 git add。
所有冲突解决后提交合并结果，查看提交图，最后推送并让其他成员同步。
1
出现 UU tasks.md 时，下一步最合理的动作是什么？
2
冲突说明至少有一位成员创建了无效提交。