cherry-pick 会复制提交而非移动；执行后在当前分支新建哈希值不同的提交，原提交保留在原分支，可能引发重复变更、冲突或敏感信息泄露，多人协作中需谨慎操作。
cherry-pick 会复制提交，不是移动
执行 git cherry-pick <commit-hash></commit-hash> 后，Git 会在当前分支上**新建一个内容相同但哈希值不同的提交**。原提交保留在原分支，新提交的 author 和 committer 时间、信息都可能不同（除非加 --no-commit 手动调整）。这点常被误认为“搬提交”，结果在后续合并时引发重复变更或冲突。
- 如果原提交含敏感信息（如临时密钥），复制后仍存在泄露风险，需同步清理两个位置
- 多人协作中，对已推送的提交做 cherry-pick 后又 force-push 原分支，极易导致他人本地历史错乱
- 使用
git cherry-pick -x <commit-hash></commit-hash>可自动在提交信息末尾追加(cherry picked from commit <hash>)</hash>，方便溯源
多个提交连续 cherry-pick 的顺序不能错
当要挑多个提交（比如 abc123 → def456 → ghi789），必须按**原始提交时间顺序**依次执行。Git 不会自动识别依赖关系，若先 pick def456 再 pick abc123，很可能因后者修改了前者依赖的代码而失败。
- 查顺序用：
git log --oneline origin/main~3..origin/main（取最近3个） - 批量执行推荐：
git cherry-pick abc123 def456 ghi789（空格分隔，顺序必须正确） - 遇到冲突中断后，解决完用
git add . && git cherry-pick --continue，别用git commit—— 否则会生成无关提交
cherry-pick 后出现冲突，和 merge 冲突处理逻辑不同
cherry-pick 的冲突提示里，BASE 是原提交的父提交，HEAD 是当前分支最新提交，而“incoming change”才是你要 pick 的那个提交的变更。这和 git merge 的三路合并视角不一致，容易看错哪边改了什么。
- 用
git status看冲突文件，再用git show <commit-hash>:path/to/file</commit-hash>查原提交内容作参考 - 不想手动解冲突？可先
git stash当前未提交改动，再 cherry-pick，避免干扰 - 彻底放弃当前 cherry-pick：用
git cherry-pick --abort，它会干净回退，比git reset --hard更安全
从 feature 分支 cherry-pick 到 main，要注意上游保护策略
很多团队在 main 分支启用了 protected branch 规则（如 GitHub/GitLab 的 require pull request），直接 git push origin main 会被拒绝。cherry-pick 本身不绕过这些限制。
- 本地完成 cherry-pick 后，应推送到个人远程分支：
git push origin HEAD:refs/heads/cherry-pick-fix-123 - 再基于该分支发起 PR，让 CI 检查、同事评审——尤其注意 cherry-pick 是否引入了原分支特有的未合入依赖
- 如果原提交来自别人分支且未合入，务必确认其改动是否稳定；盲目 pick 可能带入未验证逻辑
cherry-pick 看似简单，真正麻烦的是上下文缺失：它不带分支拓扑、不验依赖、不查 CI 状态。每次执行前，最好先 git log -p <commit-hash></commit-hash> 快速扫一眼改了什么，再决定要不要 pick，以及要不要连带 pick 它依赖的其他提交。
