问题背景
在并行开发场景下，分支管理不规范很容易把无关代码带入主线。
本次问题中，原本客诉需求在分支 test/lzh/edu_front_complaint_record 上开发。
但实习生没有基于该分支继续开发，而是在测试分支上新建了 dev_0601，随后执行了如下操作：
- 将
dev_0601合并到test/lzh/edu_front_complaint_record - 再将
test/lzh/edu_front_complaint_record合并到master
最终导致 master 不仅合入了客诉代码，还把 dev_0601 中本不该进入主线的代码一并带了进去，造成 master 分支变脏。
问题本质
这不是单纯的"代码冲突"，而是一次错误的分支合并。
关键点在于：
test/lzh/edu_front_complaint_record已经不再是纯净的客诉分支- 它在合入
master前，已经混入了dev_0601的开发内容 - 因此合并到
master时，主线被带入了额外代码
这种情况下，最稳妥的处理方式不是手工删文件，也不是直接回退 master 历史，而是撤销这次错误的 merge。
修复方案
直接撤销将 test/lzh/edu_front_complaint_record 合入 master 的那次 merge commit：
bash
git checkout master
git pull origin master
git revert -m 1 cf703065d命令解释
git checkout master
切换到 master 分支。
git pull origin master
先同步远端最新的 master，避免在过期代码上做回滚操作。
git revert -m 1 cf703065d
撤销提交 cf703065d 这次 merge 带来的改动。
这里的 cf703065d 是那次将 test/lzh/edu_front_complaint_record 合入 master 时生成的 merge commit。
为什么用 git revert 而不是 git reset
master 是共享分支，已经可能被多人拉取和使用。
如果使用 git reset --hard 回退历史，通常还需要强推：
bash
git push --force这会带来较大风险：
- 改写公共历史
- 影响其他同事本地分支
- 容易引发新的同步问题
相比之下，git revert 更安全：
- 不改写历史
- 通过新增一个"反向提交"来撤销错误改动
- 更适合
master这类公共分支
为什么要加 -m 1
cf703065d 是一个 merge commit，它和普通提交不同，有两个父提交。
可以理解为：
- 第一个父提交：合并前的
master - 第二个父提交：被合进来的
test/lzh/edu_front_complaint_record
-m 1 的意思是：
以第 1 个父提交为主线保留。
也就是说：
- 保留
master - 撤销
test/lzh/edu_front_complaint_record合进来的内容
换句话说：
bash
git revert -m 1 cf703065d表达的是：
保留
master原来的主线，撤销test/lzh/edu_front_complaint_record这次合并带来的改动。
如果误用 -m 2，就相当于站在被合并分支的视角做回滚，结果通常不是我们想要的。
经验总结
这次问题的根源并不复杂，但非常典型：
- 测试分支不应承担正式开发分支职责
- 开发分支应保持单一职责，避免混入无关代码
- 合并到
master前，需要确认源分支是否纯净 - 对公共分支的修复，应优先使用
git revert，避免直接改写历史
结论
当错误分支被合入 master 时，首先要判断问题属于哪一类：
- 如果只是局部文件冲突，处理冲突即可
- 如果是错误分支整体被合入，则应优先考虑撤销 merge
本次案例中，最合适的修复方式就是：
bash
git checkout master
git pull origin master
git revert -m 1 cf703065dgit log --oneline --merges --grep='test/lzh/edu_front_complaint_record'
它既能撤销错误合并，又不会破坏 master 的公共历史，是处理此类问题的安全方案。