cherry-pick 选中单个提交时 commit hash 可缩写（通常7位），但必须在仓库中唯一；若歧义则需补全，且不支持直接使用分支名如 main。
cherry-pick 选中单个提交时，commit hash 必须完整还是可以缩写？
Git 允许用缩写的 commit hash（通常 7 位足够），但前提是它在当前仓库中唯一。如果两个提交的前 7 位相同，git cherry-pick abc1234 会报错：error: short SHA1 abc1234 is ambiguous。此时必须补全到能唯一识别的长度，或直接用完整 hash。
实操建议：
- 日常使用
git log --oneline查看带缩写 hash 的提交列表，复制后直接粘贴进cherry-pick命令，基本不会出错 - 脚本中慎用缩写，优先用完整
commit hash避免 CI/CD 环境下因对象数据库差异导致歧义 -
git cherry-pick不接受分支名（如main）或相对引用（如HEAD~2）作为目标——除非你明确想挑 HEAD 前两步的提交，那得写成git cherry-pick HEAD~2，不是git cherry-pick main~2（后者依赖当前所在分支）
cherry-pick 多个提交时，顺序和范围怎么写才不丢提交？
多个提交不能靠空格拼接（git cherry-pick a1b2c3 d4e5f6 是合法的，但容易漏、难维护），更可靠的是用范围语法。注意：git cherry-pick A..B 挑的是「B 可达但 A 不可达」的提交，即从 A 后一个开始，到 B（含）为止 —— 这和 git log A..B 的语义一致。
常见错误现象：
- 写成
git cherry-pick B..A：结果为空，因为 A 在 B 的历史中，B..A 没有提交 - 想挑连续 3 个提交却写
git cherry-pick A B C，其中 C 是合并提交：默认会失败（因合并提交有多个 parent），需加-m 1指定主干 parent - 范围写成
A...B（三点）：这是对称差集，挑的是 A 和 B 各自独有的提交，通常不是你想要的线性应用
推荐做法：先用 git log --oneline A..B 确认要 pick 的提交列表，再执行 git cherry-pick A..B。
cherry-pick 出现冲突时，为什么不能直接 git add && git commit？
因为 git cherry-pick 是一个“进行中”的操作，冲突后 Git 会停在 CHERRY-PICKING 状态。此时直接 git commit 会创建一个普通提交，丢失原始提交的元信息（作者、时间、message），也绕过了 cherry-pick 的后续流程（比如继续、中止）。
正确流程是：
- 手动解决冲突文件，
git add <file></file>标记为已解决 - 运行
git cherry-pick --continue：自动复用原提交的 author/committer 信息和 message - 若中途想放弃，用
git cherry-pick --abort，所有改动会被清空，回到 pick 前状态 - 不想保留原 message？解决完冲突后，用
git cherry-pick --edit -x A，-x 会自动追加(cherry picked from commit A)，--edit 允许你修改 commit message
cherry-pick 到新分支后，如何验证是否真把代码带过来了？
别只信 git log 里看到了那个提交 —— cherry-pick 创建的是**新提交**（不同 hash），只是内容相同。真正的验证点是：代码变更是否生效、是否引入意外副作用。
关键检查项：
- 对比变更内容：
git show <original-hash></original-hash>和git show <new-cherry-picked-hash></new-cherry-picked-hash>，确认 patch 完全一致（author/time/msg 可不同，diff 应相同） - 检查文件状态：
git status确保没有残留的 merge/cherry-pick 元数据（如 .git/CHERRY_PICK_HEAD） - 运行测试：尤其注意被 cherry-pick 的提交是否依赖上游某次未同步的修改（比如它修了一个 bug，但该 bug 的触发条件在新分支里已被其他方式绕过或重构）
- 留意 submodule：cherry-pick 不会自动更新
.gitmodules或子模块 commit，需手动同步
最容易被忽略的是：cherry-pick 后没更新相关文档或配置文件，而原提交里隐含了这类配套改动。人眼扫 git show 输出比依赖 commit message 更可靠。
