什么是 Git 的 cherry-pick
cherry-pick 是把另一个分支上的指定提交"摘"到当前分支：git cherry-pick <哈希>，通常把改动作为新提交应用。适合热修复回合、跨分支搬个别提交；通常产生新哈希，滥用会让历史难追溯。
cherry-pick（摘樱桃）= 从别的分支挑指定的提交，把它的改动复制应用到当前分支。 merge 汇合历史，cherry-pick 选取指定提交的改动；该改动仍可能依赖未选取的其他提交。
基本用法
git checkout release-1.2
git cherry-pick a1b2c3d # 把 main 上那个修复摘过来
典型场景
- 热修复回合：main 上修的 bug 要同步到 release 分支，但 main 还有一堆不该进 release 的新功能——cherry-pick 只摘修复；
- 摘取别人的提交：同事的实验分支里有个工具函数你想先用；
- 提交错了分支：提交到 main 的功能提交摘到 feature 分支（仅在未共享的历史上考虑 reset；已共享历史应协调或用 revert 撤销）。
要点
- 摘过来的是改动（diff），通常生成新哈希的提交；
--ff在 HEAD 正好是目标提交父节点时可直接快进，保留原提交； - 简单线性历史中的连续一串可用
git cherry-pick A^..B；复杂历史先检查范围，合并提交还需用-m选择父线； - 冲突处理和 merge 一样：解决 → add →
git cherry-pick --continue。
常见问题（FAQ）
Q：cherry-pick 会导致重复提交吗？
通常会。同一改动可能以不同哈希存在于两个分支；后续 merge 基于祖先和树状态做合并，不是按 cherry-pick 记录自动跳过重复提交，结果可能干净也可能冲突。能 merge 就别滥用 cherry-pick。
Q：和 rebase 有什么区别？
rebase 把一串提交"移动"到新基点（更新正在变基的分支引用，其他分支、标签或 reflog 仍可能引用旧提交）；cherry-pick 是"复制"指定提交，原分支不动。
Q：摘取时想改提交信息？
加 -e 进入编辑器；-x 在无冲突的拾取中自动追加 "(cherry picked from ...)" 来源记录；有冲突时应核对最终提交信息。公开分支之间回合修复时可用它追溯来源。
