git cherry-pick 不能直接写分支名，因它仅选取该分支最新提交而非目标提交；必须用明确哈希或范围（如a1b2c3d^..e4f5g6h），并确认共同祖先以防patch错位或静默失败。
直接用 git cherry-pick 就行，但必须确认源提交和当前分支有共同祖先，否则 patch 可能静默错位或失败。
cherry-pick 为什么不能直接写分支名
你不能写 git cherry-pick feature 然后指望它挑出 feature 分支上“你想 pick 的那个提交”——Git 会默认挑 feature 的最新一次提交（即 feature 指向的 commit），而且这个行为容易误导。
常见错误现象：
- 误以为
git cherry-pick main是把 main 上所有新内容拿过来，其实只拿了 main 最后一个提交 - 写
git cherry-pick release/v2.1，但当前在main上，结果 pick 的是release/v2.1当前 HEAD，不是你心里想的那个 bugfix 提交
正确做法：
- 先用
git log --oneline origin/feature-branch或git log --oneline -n 10 origin/feature-branch明确看到目标提交的 hash（比如abc1234） - 复制完整或足够唯一的缩写 hash（
git cherry-pick abc1234），别依赖分支名猜 - 如果要用范围，写
git cherry-pick a1b2c3d^..e4f5g6h，不是a1b2c3d..e4f5g6h（后者不包含 a1b2c3d 的父提交，易漏首项）
cherry-pick 失败后为什么不能直接 git commit
冲突发生时，Git 进入 CHERRY-PICKING 状态，此时工作区和索引处于中间态。直接 git commit 会绕过 cherry-pick 流程，导致两个问题：
- 新提交丢失原始 author、committer 和 message，变成你本地的“手工提交”，后续无法追溯来源
- Git 不知道你已解决，后续
git cherry-pick --continue会报错，而git cherry-pick --abort也无法干净回退
必须走标准流程：
- 手动编辑冲突文件，删掉
/ <code>======/>>>>>标记，保留正确逻辑 - 运行
git add <file></file>标记为已解决（注意：不是git add .，避免误加其他改动） - 执行
git cherry-pick --continue，让 Git 自动完成提交 - 万一中途想放弃，用
git cherry-pick --abort，它会还原所有变更，回到 pick 前状态
跨分支 cherry-pick 前必须验证 base 是否一致
cherry-pick 不是复制，而是以当前 HEAD 为基点重放 diff。如果源提交依赖其前面某个未被包含的变更（比如新增了一个函数、改了接口），那 patch 很可能应用成功但逻辑崩溃——Git 不报错，你却在 runtime 才发现 crash。
实操建议：
- 先查共同祖先：
git merge-base main release/v2.1 - 再查该祖先到目标提交之间是否“干净”：
git log --oneline $(git merge-base main release/v2.1)..abc1234，确认 abc1234 及其所有父链都在这个区间内 - CI/CD 中自动化时，加校验：
git diff --quiet $(git merge-base source target) abc1234^ abc1234，返回非 0 表示 patch 不可干净应用 - 若依赖断裂，优先考虑基于源分支切临时修复分支再合并，而不是硬 pick
最容易被忽略的一点：cherry-pick 后的新提交哈希值完全不同于原提交，且没有自动关联关系。如果你后续在两个分支间做 git merge，Git 不会因为内容相同就跳过——它只看 commit graph，不是 content graph。这意味着重复 cherry-pick 可能引入逻辑冗余，也意味着你得靠 -x 或人工注释来维持可追溯性。
