git cherry-pick 是最直接将单个提交改动精准移植到目标分支的方式，它仅重放指定提交的 diff 补丁，不合并整个分支；需确保目标分支干净、HEAD 最新，并注意 cherry-pick 后提交哈希必然改变。
git cherry-pick 能直接拿单个提交到目标分支
想把某次提交的改动搬到另一个分支，git cherry-pick 是最直接的方式。它不合并整个分支，只“挑”出你指定的那次提交（及其 diff），在当前分支上重放一次。
常见错误是先切到目标分支再执行，却忘了检查当前 HEAD 是否干净——如果工作区或暂存区有未提交变更，git cherry-pick 会失败并报错 error: Your local changes would be overwritten by cherry-pick.
- 先确保目标分支已更新：
git checkout target-branch && git pull - 用
git log --oneline -n 5找到要搬运的提交哈希（比如a1b2c3d） - 执行：
git cherry-pick a1b2c3d - 如有冲突，解决后
git add . && git cherry-pick --continue
多个提交连续搬运要注意顺序和冲突累积
如果要搬的是连续的几次提交（比如从 A→B→C），git cherry-pick A^..C 可以一次性选中（注意 A^..C 表示“从 A 的父提交之后到 C”，即包含 A、B、C）。但顺序必须是从旧到新，否则会出错。
容易被忽略的是：连续 cherry-pick 过程中，前一个提交的修改会影响后一个提交的上下文。哪怕单个提交在原分支能编译通过，合在一起可能因中间状态缺失而冲突更剧烈。
- 推荐分步操作，每次
cherry-pick后立刻测试关键逻辑 - 避免用
cherry-pick A..C（漏掉 A），正确写法是A^..C或A~2..C - 如果中途出错，用
git cherry-pick --abort退出，别硬着头皮--continue
cherry-pick 后的提交哈希会变，不能靠哈希跨分支追踪
cherry-pick 产生的新提交，即使内容一致，哈希值也完全不同——因为父提交变了，作者时间可能微调，Git 的哈希是内容+元数据全量计算的。这意味着：
- 不能用
git merge-base或git branch --contains反向查“这个提交是不是从某分支 cherry-pick 来的” - CI/CD 流水线若依赖提交哈希做制品绑定，需确认是否允许 cherry-pick 场景
- 如果团队用
git revert回滚某功能，记得 revert 原始提交，而不是 cherry-pick 后的那条——否则只回退了目标分支上的副本，源分支仍存在
替代方案：rebase 或 merge？什么情况下不该 cherry-pick
如果要同步的是一长串逻辑连贯的提交，且目标分支长期需要这些改动，git rebase（把整个分支变基过去）或 git merge（正向合并）通常比反复 cherry-pick 更可靠。cherry-pick 是“补丁式操作”，适合修复、热更、小范围功能移植。
- 当提交之间有依赖（比如 B 用了 A 新增的函数），又不是连续提交时，cherry-pick 容易漏依赖，应优先考虑
merge - 如果目标分支已存在部分相同修改（哪怕只是手动抄代码），cherry-pick 可能触发“空提交”或意外覆盖，此时建议人工比对
git diff - GitHub/GitLab 上 PR 关联的提交，cherry-pick 后原始 PR 状态不会自动更新，别误以为“同步完成=PR 已合入”
实际用的时候，最常卡住的不是命令不会输，而是没意识到 cherry-pick 后的提交已经和原来不是“同一个东西”——哈希不同、历史断开、无法追溯来源。这点在做跨仓库同步或审计时特别关键。
