结论：用两个本地仓库目录（如dev-alice和dev-bob）加一个远程仓库，即可完整复现所有常见Git冲突场景；关键在于让Git识别到两个独立工作区对同一文件同一区域的不可合并修改，无需多人或多账号。
直接说结论：不需要找别人、不用开多个账号，用两个本地仓库目录 + 一个远程仓库，就能完整复现所有常见 Git 冲突场景。
用两个本地 clone 目录模拟不同开发者
这是最干净、可重复、零权限依赖的模拟方式。关键不是“装两个人”，而是让 Git 看到两个独立的工作区对同一远程分支做了不可合并的修改。
- 在项目根目录下执行
git clone . ../dev-bob（假设当前是dev-alice），快速创建第二个本地副本 - 两个目录各自独立：
git config user.name "Alice"和git config user.name "Bob"，避免提交信息混淆 - 不要用
git remote add重复添加 origin——两个目录都应指向同一个远程仓库（如git@gitee.com:team/proj.git） - 确保远程已有
develop分支（可通过git push origin develop初始化，或在 Gitee 页面手动创建）
制造 CONFLICT (content) 的最小操作链
冲突只发生在 Git 尝试自动合并时发现同一文件的同一段被两方修改。重点不在“谁先谁后”，而在“Git 能否找到共同祖先并判断修改是否重叠”。
Git Changelog Generator
下载
使用约定式提交（Conventional Commits）从 Git 历史记录中生成结构化变更日志，支持多种格式、AI 增强型描述以及可自定义的范围……
- Alice 在
dev-alice/中修改src/api.js第 12 行，git commit -m "add timeout config"，再git push origin develop - Bob 在
dev-bob/中**不先 pull**，直接修改src/api.js第 12 行（哪怕只是改个空格），git commit -m "fix typo in timeout" - Bob 执行
git push origin develop→ 触发! [rejected] develop -> develop (non-fast-forward) - 此时 Bob 运行
git pull origin develop→ 立即出现CONFLICT (content): Merge conflict in src/api.js
为什么 git stash 不适合教学级冲突演练
git stash 会把工作区变更暂存为一个匿名提交，再执行 git pull（即 fetch + merge）。它掩盖了“本地修改 vs 远程新提交”这一原始冲突条件，导致你看到的是 stash 与远程的三路合并，而非两个真实开发者的直接交锋。
- 真实协作中，没人会先
stash再拉取——他们要么已提交，要么还没动代码 - 用
stash演练，git status显示 “clean”，但实际冲突被隐藏在 stash 栈里，新手容易误以为“没冲突” - 想观察原始冲突标记（
<<<<<< HEAD/======/>>>>>> origin/develop），必须让修改处于未提交状态且远程已有新提交
rebase 模拟比 merge 更贴近日常 PR 场景
很多团队要求 feature 分支在合入前必须 rebase 到最新 develop，这时冲突发生在变基过程中，而非 merge 提交里。这种冲突解决后不会留下 merge commit，更接近 CI/CD 流水线中的实际失败点。
- Bob 切到自己分支：
git checkout -b feat/login dev-bob/ - 修改
login.vue后git commit - Alice 已把另一版
login.vue推上develop - Bob 执行
git rebase develop→ 卡在冲突，提示First, rewinding head to replay your work on top of it... - 解决后
git add login.vue && git rebase --continue，完成变基
注意：rebase 会重写 commit hash，所以仅限本地分支使用；一旦 feat/login 已推送到远程，就别再 rebase —— 否则队友 git pull 时会拉下重复提交或丢失历史。
