git cherry-pick 默认无法处理 merge 提交，因需明确以哪个父提交为基准计算差异；必须用 -m 参数指定主父序号，-m 1 以第一个父（如 main）为基准，-m 2 以第二个父（如 feature）为基准提取实际新增改动。
git cherry-pick 默认无法直接处理 merge 提交（即拥有两个或以上父提交的提交），因为 Git 不知道该以哪个父分支为基准来计算差异。这时必须用 -m（或 --mainline）参数明确指定“主父提交”的序号，才能让 cherry-pick 正确还原变更逻辑。
为什么 merge 提交需要 -m 参数
普通提交只有一个父提交，cherry-pick 只需对比它与父提交的差异即可。而 merge 提交（如通过 git merge feature 生成）有两个父：第一个是当前分支（如 main）的最新提交，第二个是被合并分支（如 feature）的 tip。Git 默认把第一个父当作“主线”，但如果你要提取的是来自 被合并分支 的变更内容（即真正新增的代码逻辑），就必须告诉 Git：“请以第二个父为基准”——这就是 -m 2 的含义。
如何确定该填 -m 1 还是 -m 2
关键看你想保留哪条路径的上下文：
抓取指定 GitHub用户的 Stars 项目，生成标准化中文 Markdown 报告。用户提及「分析 GitHub stars」「导出收藏项目」「汇总 GitHub 星标」「生成 stars 报告」或粘贴含 ?tab=stars 的链接时触发。执行通过 bash...
- -m 1：以第一个父（通常是目标分支，如 main）为基准 → 提取的是“合并操作本身带来的变化”，通常只是更新指针，几乎无代码变更
- -m 2：以第二个父（通常是源分支，如 feature）为基准 → 提取的是“feature 分支上实际新增的改动”，这才是你通常想复用的内容
- 三路合并中若有更多父（罕见），序号按
git show --pretty=%P <merge-commit></merge-commit>输出顺序从 1 开始编号
操作步骤示例
假设你在 main 分支上执行了 git merge feature，生成 merge 提交 abcd123，现在想把它“摘”到 release 分支：
- 先切到 release 分支：
git checkout release - 查看 merge 提交结构：
git show --pretty=full abcd123或git cat-file -p abcd123 | head -5，确认父提交顺序 - 执行 cherry-pick 并指定主父：
git cherry-pick -m 2 abcd123 - 如有冲突，解决后
git add .，再git cherry-pick --continue
常见误区提醒
不加 -m 直接 cherry-pick merge 提交会报错：fatal: commit ... is a merge but no -m option was specified。这不是 Bug，而是 Git 的保护机制。另外，-m 不影响新提交的哈希或内容正确性，只决定“差分计算的参考点”。选错会导致 cherry-pick 出空提交或反向变更，务必结合 git diff 验证结果。
