git cherry-pick 一次可选多个提交，直接写 git cherry-pick abc123 def456 ghi789 即按所列顺序依次应用；也支持范围写法如 A^..B，冲突时中止并需 git cherry-pick --continue 或 --abort 恢复。
cherry-pick 一次选多个提交怎么写命令
直接用 git cherry-pick 加一串 commit hash 即可，不需要额外参数。Git 会按顺序依次应用这些提交（注意：不是按时间顺序，而是你列出的顺序）。
- 最常用写法：
git cherry-pick abc123 def456 ghi789 - 支持范围写法：
git cherry-pick A^..B表示从 A 的父提交开始，到 B（含）为止的所有提交（注意是半开区间A^..B，不是A..B） - 如果想排除某个提交，用
^前缀：git cherry-pick A^..C ^B表示 A 到 C 之间除 B 外的所有提交 - 执行前建议先
git log --oneline A^..B确认范围，避免误 pick
遇到冲突时 cherry-pick 会停在哪一步
只要任意一个提交应用失败（比如有冲突或 patch 失败），git cherry-pick 就会立即中止，停留在当前出错的提交上，不会继续往后执行。此时工作区处于“cherry-pick in progress”状态。
- 解决冲突后，用
git add <file>标记已解决，再运行git cherry-pick --continue - 想放弃整个操作，用
git cherry-pick --abort—— 这会还原所有已成功 pick 的提交（哪怕只成功了一个） - 跳过当前出错的提交（不推荐），用
git cherry-pick --skip，但后续提交仍可能因依赖关系失败 - 注意：
--abort不能恢复被修改但未 commit 的本地文件，仅回退 cherry-pick 自身引入的变更
cherry-pick 后的提交 hash 会变吗
会变。每个被 pick 的提交都会生成一个**新 commit**，author 和 committer 时间、parent 关系都不同，所以 hash 必然不同。原始提交的 git show 输出里能看到 (cherry picked from commit xxx) 注释，这是 Git 自动加的。
- 这意味着：不能靠 hash 判断是否已 merge 过，得比对内容或看 git log 中的 cherry-pick 标记
- 如果目标分支已有相同 patch（哪怕 hash 不同），
git cherry-pick会提示 “already applied”，默认跳过（可用--allow-empty强制重试） - 多人协作时，不要对已推送的提交反复 cherry-pick，容易造成重复逻辑或历史混乱
批量 cherry-pick 时如何避免漏掉或重复
核心是把“哪些提交要 pick”这个清单固化下来，而不是靠肉眼数 commit 或凭记忆敲命令。最容易出问题的是范围边界和合并顺序。
- 用
git log --cherry-pick --oneline A...B查看 A 和 B 分支间尚未被 cherry-pick 过的提交（需两个分支都有共同祖先） - 导出待 pick 列表：
git rev-list --reverse A^..B > picks.txt，然后逐行检查、删减，再用xargs git cherry-pick < picks.txt - 如果源分支有大量无关提交（比如 fixup、WIP），先用
git log --grep="keyword"或--author过滤，再生成列表 - 执行前切到目标分支并确保 clean：
git status应该显示 “nothing to commit, working tree clean”
