使用场景
在实际开发中，我们并不总是需要合并整个分支。Git Cherry-Pick 的核心价值在于'选择性应用'。比如，当稳定版需要紧急修复某个 Bug，而该修复只在开发分支完成时，直接合并整个开发分支可能会引入未测试的新功能。这时，Cherry-Pick 就能精准地把那个特定的提交'移植'过来。
另外，在维护多个长期分支（如 v1.0, v2.0）时，经常需要从主分支提取某些功能补丁到旧版本。或者在整理提交历史时，想把几个零散的提交压缩成一个逻辑清晰的提交，配合 Rebase 使用效果更佳。
基本用法
最基础的用法是指定单个提交的哈希值。假设你想把 feature 分支上的某个修复应用到 main 分支：
git checkout main
git cherry-pick a1b2c3d
如果目标分支和源分支存在差异，Git 会尝试自动合并；若发生冲突，终端会提示你需要手动解决文件冲突。解决完冲突后，执行 git cherry-pick --continue 即可完成本次操作。
批量挑选
如果需要连续应用多个提交，可以直接指定范围。例如从 commit A 到 commit B 之间的所有提交：
git cherry-pick A..B
注意这里的顺序，Git 会按时间顺序依次应用。如果想跳过中间某个提交，可以结合 --no-commit 参数先暂存更改，调整后再提交。
避坑指南
Cherry-Pick 生成的新提交会有新的哈希值，这意味着它不是原提交的'复制'，而是基于当前环境重新应用的'快照'。因此，不要频繁对公共分支进行 Cherry-Pick 后再强制推送，这会导致历史线混乱。如果是为了清理本地杂乱提交，建议先用 Rebase 整理好再推送到远程。