Recovery
cherry-pick 挑错提交后的恢复
当 cherry-pick 了错误提交或错误顺序后，根据是否已共享分支历史，选择 reset、revert 或重建补丁链恢复正确状态。
- 正在处理 Git 误操作的人
- 想提前建立保守恢复习惯的协作者
- 先停手，不继续乱试命令
- 能执行 `git reflog`、`git status`、`git log --graph`
- 还没保住旧位置就继续 reset / rebase
- 在没判断影响面时直接改共享历史
引用与延伸阅读
- Git cherry pick [官方]
- Git reset [官方]
- Git revert [官方]
学完这篇你会掌握什么
- 理解 cherry-pick 挑错提交后的恢复 的核心作用和适用场景
- 掌握 cherry-pick 挑错提交后的恢复 的基本用法和常用参数
- 当 cherry-pick 了错误提交或错误顺序后，根据是否已共享分支历史，选择 reset、revert 或重建补丁链恢复正确状态。
- 理解 决策边界 相关的概念
- 掌握 快速定位 pick 前位置 相关的操作
- 知道在什么场景下使用该命令，什么场景下避免使用
挑错提交后第一步不是立刻“撤销”，而是先判断这段历史是否已经推送给别人。
先想一个问题
你刚刚在 Git 里做了一个操作，结果发现不是你想要的效果——甚至可能弄丢了提交。这种情况不是第一次了，你想建立一套可靠的方法来应对各种误操作场景。
决策边界
- 未共享：通常可以用
reset回到 pick 前 - 已共享：优先
revert保持公共历史可解释
错误 pick 的提交
main
ABC
feature
BDE
当前分支
release
AR1E'
快速定位 pick 前位置
git reflog
找到 cherry-pick 前的位置后先建救援分支：
git switch -c rescue/pre-wrong-pick HEAD@{2}
两种典型恢复路径
未共享分支
git reset --hard HEAD@{2}
已共享分支
git revert <wrong-picked-commit>
然后再按正确顺序重新 cherry-pick。
处理“顺序错但提交都要”场景
这类问题建议在临时分支重排顺序并验证后，再合并回主线，避免在主线上反复改写。
共享历史上的 reset 会把问题转移给协作者。对公共分支，revert 通常更安全也更可审计。
接下来建议继续看什么
给你的练习
- 在一个测试仓库中练习该命令的基本用法，观察执行前后的状态变化
- 尝试该命令的不同参数选项，对比输出结果的差异
- 模拟一个需要使用该命令的实际场景，完整走一遍操作流程
延伸阅读
沿着同一主题继续深入：