撤销与恢复
你将学会什么
Section titled “你将学会什么”- 区分
git reset与git revert的适用场景 - 理解
cherry-pick的适用边界，避免“摘一半”的坑 - 拿不准时优先选
revert
很多学生会把“撤销提交”当成单一操作，但 Git 里实际上有两种思路：
git reset：更适合本地整理提交历史，风险是会改提交记录git revert：更适合共享分支，因为它会新增一个反向提交，而不是删旧记录
如果你不确定分支是否已经推送，优先选 revert。只有在本地私有分支上想“重新来一次”时，才考虑 reset。
git cherry-pick 不是“复制提交”这么简单。它适合：
- 把某个修复从发布分支单独摘到主分支
- 在跨课程项目复用一个小功能时，避免合并整条分支
不适合的场景：
- 当前提交依赖后续提交，单独摘取会导致编译失败
- 同一个功能已经被拆分到多个提交，只 cherry-pick 其中一半
如果你拿不准，优先先合并，再让队友一起确认。
先自己回答，再看答案：
reset和revert对提交历史的影响有什么不同？- 什么场景下
cherry-pick容易出问题？ - 分支可能已经推送时，撤销提交首选哪个命令？
参考答案
- reset 改写历史（删旧记录），revert 新增反向提交（不删旧记录）。
- 提交依赖后续提交、或功能被拆成多个提交时，单独摘取会不完整。
git revert，因为不破坏共享历史。
reset改写历史，只适合本地私有分支revert新增反向提交，是共享分支的安全选择cherry-pick只摘独立完整的提交，拿不准就先合并