cherry-pick 是补丁重演而非复制，生成新哈希、新时间戳和新父提交；同一提交多次 cherry-pick 会产生内容相同但哈希不同的“孪生提交”，merge 无法自动跳过。
cherry-pick 会改写提交哈希，不是“复制”而是“重演”
执行 git cherry-pick <commit-hash></commit-hash> 时，Git 并不是把原提交原封不动搬过来，而是以当前 HEAD 为基点，重新应用该提交的补丁（diff）。这意味着新生成的提交拥有全新哈希值、新时间戳、新作者信息（除非加 --no-commit 手动干预），且父提交指向当前分支 HEAD。
常见错误现象：
• 同一提交在多个分支上反复 cherry-pick，结果产生一堆哈希不同但内容雷同的“孪生提交”，后续 git merge 可能意外跳过冲突或重复变更；
• 误以为 cherry-pick 后原提交就“被合并了”，其实原分支历史完全没变，也不影响后续 merge-base 计算。
- 如果想保留原始作者和时间，用
git cherry-pick --allow-empty --keep-redundant-commits --no-edit --signoff组合并不保险，真正可靠的是git cherry-pick -x（自动加(cherry picked from commit ...)注释）+ 手动git commit --amend --author="..." --date="..." - 涉及多个提交时，
git cherry-pick A^..B表示“从 A 的父提交开始，到 B（含）为止”，注意这不是闭区间 A..B；A..B 实际是“B 可达但 A 不可达”的提交，顺序和包含关系容易反直觉 - cherry-pick 失败后进入冲突状态，解决完必须
git add+git cherry-pick --continue，不能git commit—— 否则会生成两个提交：一个半成品 + 一个手工提交，破坏原子性
跨分支 cherry-pick 前必须确认 base 是否一致
所谓“只合并指定提交”，隐含前提是：目标分支与源提交所在分支在该提交之前有共同祖先。否则，patch 可能因上下文缺失而失败，或看似成功实则逻辑错位。
使用场景举例：
• 主干 main 上修复了一个 bug，提交为 abc123，你想把它 pick 到已发版的 release/v2.1 分支；
• 但若 release/v2.1 是从 main 的更早节点切出，且 abc123 依赖其前一个提交里新增的函数签名，那 cherry-pick 就会报错或静默引入不兼容变更。
- 先运行
git merge-base main release/v2.1，再查git log --oneline $(git merge-base main release/v2.1)..abc123，确认 abc123 及其依赖链是否全在该 merge-base 之后 - 如果依赖链断裂，不要硬 pick，优先考虑
git revert+git cherry-pick组合，或直接基于abc123所在分支新建临时修复分支再合并 - CI/CD 中自动化 cherry-pick 时，务必加
git diff --quiet $(git merge-base source-branch target-branch) <commit-hash>^ <commit-hash></commit-hash></commit-hash>验证补丁是否可干净应用，避免静默损坏
cherry-pick 后的提交无法被 git merge 自动跳过
很多人以为：既然某提交已被 cherry-pick 过，下次 merge 源分支时 Git 就会识别并跳过它。这是错的。Git 的 merge 算法只看 commit 哈希，不比较 patch 内容。cherry-pick 出来的提交哈希不同，对 merge 来说就是全新提交。
后果很实际：
• 后续执行 git merge main 到 release/v2.1，即使其中已含 cherry-picked 的 abc123 衍生提交，Git 仍会尝试合并 abc123 本身，大概率触发冲突；
• 若强行 resolve 并提交，可能造成重复逻辑、字段覆盖或状态错乱。
- 预防方式只有两种：要么在 merge 前手动排除（
git merge --no-ff --no-commit main && git reset HEAD~1 && git checkout -- . && git commit -m "merge main minus cherry-picked fixes"，高风险，慎用）；要么接受现实，在团队协作中明确定义“cherry-pick = 临时救火，后续必须同步回源分支并走完整 merge 流程” -
git patch-id可用于人工比对补丁唯一性，例如git show abc123 | git patch-id和git show def456 | git patch-id输出相同，说明内容一致，但这不能被 Git 内建 merge 机制利用 - 如果项目重度依赖 cherry-pick，建议启用
git config --global rerere.enabled true，至少让重复冲突能自动复用上次 resolution
revert 比 cherry-pick 更适合“反向同步”场景
当你要把某个 hotfix 从 release/v2.1 “撤回到” main（比如发现该修复不该进主干），别用 cherry-pick，用 git revert。
原因很简单：
• cherry-pick 是正向搬运，你得手动找对提交、处理依赖、再解决冲突；
• revert 是生成一个“逆操作”提交，语义清晰、可追溯、天然兼容 merge 策略，而且 revert 本身也能被 cherry-pick —— 形成可审计的操作链。
- 正确流程：
git checkout main && git revert -m 1 <merge-commit-hash></merge-commit-hash>（如果是合并提交）或git revert <hotfix-commit-hash></hotfix-commit-hash>（单提交） - 如果 hotfix 提交已被多人 cherry-pick 到不同分支，revert 它只会撤销 main 上的影响，其他分支不受干扰 —— 这正是你想要的隔离性
- 注意
git revert默认生成新提交，若想压成一个（比如批量 revert 多个），需加--no-edit+git reset --soft HEAD~n && git commit，但会丢失每个 revert 的原始注释，不推荐
事情说清了就结束。cherry-pick 看似轻量，实则每一步都在改写历史上下文；最容易被忽略的，是它和 merge、revert 在 Git 内部认知模型里的根本不对等——前者是补丁重演，后两者才是真正的拓扑操作。
