cherry-pick 是重放差异而非复制提交，会生成新哈希、新时间戳和新父提交；同一提交多次 cherry-pick 产生内容相同但哈希不同的“孪生提交”，merge 无法自动跳过。
cherry-pick 不是“复制提交”，而是重放差异；直接照搬哈希执行，大概率会在目标分支上触发冲突或产生语义错误。
cherry-pick 为什么会创建新提交而不是复用原提交
Git 的每次提交都绑定其父提交哈希、作者时间、树对象（文件快照）和提交信息。git cherry-pick 实际上是计算 commit^..commit 的 diff，再把这个 patch 尝试应用到当前 HEAD 上。成功后，Git 会基于当前工作区状态生成一个全新提交：新的哈希、新的提交时间、新的父提交（即当前 HEAD），但默认保留原提交信息和变更内容。
这意味着：
- 即使内容一致，
f和f'在 Git 历史中是两个完全独立的对象，git log --all --oneline里会看到两行不同哈希 - 如果你后续在多个分支上反复
cherry-pick同一修复，Git 无法自动识别“这其实是同一个逻辑变更”，可能造成重复修复或回滚困难 - 使用
-x参数（即git cherry-pick -x f）会在提交信息末尾追加(cherry picked from commit f)，这是唯一能人工追溯来源的可靠线索
连续提交范围写错顺序会导致静默失败
当你想挑 e → f → g 这三个连续提交时，正确写法是 git cherry-pick e^..g（含 e）或 git cherry-pick e..g（不含 e）。但若写成 g..e，Git 不报错，也不做任何事——命令直接返回成功，但实际没应用任何提交。
排查建议：
- 先用
git log --oneline e^..g确认范围是否包含预期提交 - 对不确定的范围，优先用离散列表：
git cherry-pick e f g，虽然多敲几下，但行为确定 - 避免在脚本中硬编码范围，尤其当源分支持续更新时，
e..g可能随时间漂移，导致漏 pick 或重复 pick
冲突发生时，--abort 和 --quit 的区别很关键
cherry-pick 过程中遇到冲突，Git 会停在中间状态：git status 显示 unmerged paths，HEAD 未移动，工作区已修改但未提交。
此时你有两个主要退出选项：
-
git cherry-pick --abort：彻底回退，撤销所有已暂存的变更，恢复到 cherry-pick 开始前的状态（相当于什么都没发生） -
git cherry-pick --quit：放弃当前 cherry-pick 流程，但**保留已成功应用且已git add的变更**——这些变更会留在暂存区，你需要手动git reset或git checkout -- .清理，否则下次提交会意外带上它们
多数人误用 --quit 后发现“怎么多出了不该有的代码”，问题就出在这里。
图形化工具（VSCode / TortoiseGit）不能绕过原子提交原则
VSCode 的右键 “Cherry Pick Commit” 或 TortoiseGit 的“Cherry Pick”菜单，确实让操作更直观，但它们不解决底层约束：如果原提交本身违反原子性（例如一个提交同时改了支付逻辑 + 调整了 UI 配色 + 修复了日志格式），那 cherry-pick 过来后，你在目标分支上要么全收，要么全拒——没法只挑其中一部分。
所以真正省事的前提是：
- 源提交必须是单一职责：只修复一个 bug，或只新增一个函数，或只调整一处配置
- 提交信息要具体，比如
[auth] fix JWT token expiry check in /api/login，而不是update some files - 团队需约定：hotfix/feature 分支上的每个提交都应能独立 cherry-pick，否则图形化只是把麻烦从命令行转移到了 GUI 里
精细迁移的难点从来不在命令怎么敲，而在于历史是否干净、意图是否清晰。cherry-pick 是把手术刀，但动刀前得先看清解剖结构——否则切得再准，也救不了病。
