cherry-pick单个提交：只搬修复，不把整个分支合并进来

另一个分支只有一处修复需要上线时，可以选择性应用提交。本文说明操作前检查、冲突处理与完成后的验证。

功能分支还没有开发完，却包含一个主分支急需的修复，此时可以考虑 cherry-pick。它把指定提交的改动应用到当前分支，通常产生新的提交，并不是移动原来的那条历史。

先检查提交依赖

保存工作区修改，再查看目标提交的差异和前后关系。如果修复依赖前一个提交新增的接口，只搬最后一条可能无法运行。先切到目标分支，从最新基线创建修复分支，确认当前分支正确后再执行 git cherry-pick 加提交编号。

冲突时不要硬选一边

运行 git status 查看冲突文件，理解目标分支现有实现，再编辑冲突区域。解决后把指定文件加入暂存区，执行 git cherry-pick --continue。决定放弃本轮操作时，可用 --abort 回到操作前的状态；先确认没有需要单独保存的临时编辑。

验证实际行为

检查最终差异是否只包含预期修复，运行受影响功能的检查，再提交拉取请求。跨分支回移修复时，可按团队规则保留原提交来源说明，帮助后来的人追踪关系。

不要把 cherry-pick 当作长期同步分支的工具。大量相互依赖的提交更适合重新设计合并策略。合并提交还涉及父提交选择，未理解之前不要随意加参数尝试，以免带入与预期不同的改动。

参考资料

资料核对：2026年10月27日。本文为文档综合与操作建议，未宣称完成本站实测。

Git cherry-pick 手册

Git switch 手册