结论：git cherry-pick a..b 选的是从 a 的下一个提交开始、到 b（含）为止的所有提交，不包含 a；若需包含 a，必须写 a^..b 或 a~1..b。
Git cherry-pick 范围语法到底怎么写才不丢提交
直接说结论：git cherry-pick A..B 选的是「从 A 的下一个开始，到 B（含）为止」的所有提交，不是数学意义上的区间。很多人误以为 A..B 包含 A，结果漏掉一个关键修复；也有人用 A...B（三个点），却没意识到它走的是“共同祖先”逻辑，跨分支时行为完全不同。
实操建议：
-
A..B是最常用范围形式，适用于线性历史（比如从main切出的feature分支想同步回 main） - 如果 A 和 B 不在同一条直线上（比如两个并行开发的 release 分支），
A..B可能选出大量无关提交；此时应先用git log A..B --oneline预览，再决定是否加--no-merges过滤合并提交 - 别用
A...B代替A..B—— 它等价于$(git merge-base A B)..B，在你没确认共同祖先时，结果极不可控
cherry-pick 多个提交时如何避免冲突叠加
连续 cherry-pick 多个提交，一旦中间某个提交应用失败，后续提交不会自动跳过，而是全部卡住。更麻烦的是：如果强行 git cherry-pick --continue 而没重置工作区，后面提交会在已修改的文件上继续打补丁，冲突会越滚越大。
安全做法：
- 始终用
git cherry-pick --no-commit A..B批量暂存变更，再统一git commit—— 这样所有改动合为一次提交，避免中间状态污染 - 若必须保留原始提交粒度，就拆成单次执行：
git cherry-pick <hash1></hash1>→ 解决冲突 →git add . && git cherry-pick --continue→ 再git cherry-pick <hash2></hash2>… 不图快，图稳 - 提前建临时分支操作：
git checkout -b sync-temp B，再git cherry-pick A..B，出错可直接git reset --hard回退，不影响原分支
同步到旧版本分支时，cherry-pick 报错 “commit is a merge but no -m option was provided”
这是遇到合并提交（merge commit）的典型报错。Git 默认不处理合并提交，因为不知道该 pick 哪条父路径的变更。
解决路径很明确：
- 先确认这个 merge 提交是否真有必要同步：多数情况下，只同步普通提交就够了，用
git cherry-pick --no-merges A..B直接跳过 - 如果确实要 pick 合并提交（比如修复了 merge 引入的 bug），必须指定主父提交（通常是第一个父提交）：
git cherry-pick -m 1 <merge-hash></merge-hash> -
-m 1表示“以该 merge 的第一个父提交为基准”，-m 2是第二个父（即被合并进来的分支），绝大多数场景用-m 1
cherry-pick 后发现作者信息/时间戳变了，影响审计怎么办
默认 git cherry-pick 会把 committer 改成当前用户、时间戳设为当前时间，但 author 信息保留原样。这对 Git 记录溯源其实够用；但如果你们的 CI/CD 或合规流程严格要求「作者 = 提交者」且时间不可变，就得干预。
两种可控方式：
- 加
--no-commit后手动git commit --author="Old Author <old>" --date="2023-05-12 14:30:00"</old>，适合少量提交 - 批量处理推荐用
git filter-repo（非 cherry-pick 本身，但常用于事后修正）——不过这属于重写历史，仅限未推送的临时分支 - 注意：
--author和--date只对新生成的 commit 生效，无法还原原始 committer 字段；Git 设计上就不支持伪造 committer
真正容易被忽略的是：cherry-pick 产生的新 commit hash 会让依赖精确 commit ID 的自动化流程（如部署清单、二进制制品绑定）失效，这种场景下，与其硬同步，不如考虑 tag + submodule 或 semantic versioning 配合发布分支管理。
