如何通过交互式Git Rebase实现带合并提交处理的批量Cherry-Pick？

好消息！其实Git的交互式rebase本身就支持给单个提交的pick命令附加cherry-pick的参数，包括你需要的-m选项，完全能满足你的需求，不用额外写脚本。

具体操作步骤 #

1. 启动交互式rebase
   执行你原本想用的命令：

   git rebase -i --onto myBranch myBranch
   

   这个命令的作用是从myBranch的当前状态开始，把你指定的提交重放到myBranch上，刚好适合批量拣选提交的场景。

2. 修改交互式编辑界面的命令
   编辑器弹出后，你会看到一系列pick <commit-hash>的行：

   • 对于普通提交，保持pick <commit-hash>（或者缩写p <commit-hash>）不变；
   • 对于合并提交，把对应的行改成pick -m 1 <commit-hash>（这里的-m 1和你用git cherry-pick -m 1时的含义完全一致，指定以第一个父提交作为基线）。

   举个例子，你的编辑内容可能会变成：

   p 1234          # 普通提交，直接拣选
   pick -m 1 3224  # 合并提交，指定-m 1参数
   p 5678          # 普通提交
   pick -m 1 abcde # 合并提交
   

3. 执行并处理冲突
   保存退出编辑器后，Git会按顺序处理每个提交：

   • 普通提交直接完成拣选；
   • 合并提交会用你指定的-m 1参数来处理；
   • 遇到冲突时会自动暂停，让你手动解决冲突。解决后执行git add <冲突文件>，然后用git rebase --continue继续处理剩下的提交，或者用git rebase --abort终止整个流程，git rebase --skip跳过当前提交。

为什么之前的方法出错？ #

你之前尝试给git rebase命令本身加-m选项是没用的——Git里rebase的-m选项是用来保留提交链中的合并提交结构的，而不是给单个拣选的合并提交指定父基线。正确的做法是把-m参数加到每个合并提交对应的pick命令后面，这样Git才会把这个参数传递给处理该提交的cherry-pick操作。

对比cherry-pick脚本的优势 #

用逐个执行git cherry-pick -m 1的脚本最大的问题是：一旦某个提交冲突，后续所有的cherry-pick命令都会因为工作区存在未合并文件而直接失败，你必须解决冲突后再手动执行剩下的每一条命令，非常繁琐。而交互式rebase会在冲突时暂停，解决后只需要一个--continue就能自动继续处理剩下的所有提交，流程顺畅得多，完全保留了你想要的“遇到问题暂停、手动干预后继续”的特性。

额外注意事项 #

• 如果你不确定合并提交的父提交序号，可以用git show <commit-hash>查看，输出中会有Merge: aaaaaaa bbbbbbb的行，第一个哈希是父1，第二个是父2；
• 除了pick，你也可以给其他rebase命令加-m参数，比如edit -m 1 <commit-hash>，这样拣选完该合并提交后会暂停，让你修改提交内容；
• 确保你使用的Git版本足够新（Git 2.23+应该都支持这个特性，更早的版本可能有兼容性问题）。

内容的提问来源于stack exchange，提问作者Brad