从git v1.7.2起，cherry-pick可以接受一系列提交：

git cherry-pick学会了选择一系列提交（例如cherry-pick a..B和cherry--pick-stdin），git revert也学会了选择；然而，这些并不支持rebase[-i]所具有的更好的测序控制。

正如Gabe Moothart所指出的，cherry pick A..B不会得到commit A（你需要A~1..B），如果有任何冲突，git不会像rebase那样自动继续（至少在1.7.3.1）。

是否确实不想合并分支？如果工作分支有一些您不需要的最近提交，您可以在您需要的位置创建一个带有HEAD的新分支。

现在，如果出于任何原因，你真的想要挑选一系列提交，那么一个很好的方法就是只需提取一个补丁集并将其应用于新的集成分支：

git format-patch A..B
git checkout integration
git am *.patch

这基本上就是git rebase所做的，但不需要玩游戏。如果需要合并，可以向git-am添加--3way。如果您逐字遵循说明，请确保执行此操作的目录中没有其他*.patch文件。。。

另一种选择可能是将我们的策略合并到范围之前的提交，然后与该范围的最后一次提交（或当它是最后一次时的分支）进行“正常”合并。因此，假设只有2345和3456个主提交要合并到功能分支中：

master:
1234
2345
3456
4567

在功能分支中：

git merge -s ours 4567
git merge 2345

如果你只有两次提交，并且想挑选，你可以

git cherry-pick <commit> -n

然后将它们转换为新的提交。

-n不会自动创建提交，而只是阶段性地进行更改，因此您可以继续对提交中的文件进行cherry pick或更改。

从git v1.7.2起，cherry-pick可以接受一系列提交：

git cherry-pick学会了选择一系列提交（例如cherry-pick a..B和cherry--pick-stdin），git revert也学会了选择；然而，这些并不支持rebase[-i]所具有的更好的测序控制。

正如Gabe Moothart所指出的，cherry pick A..B不会得到commit A（你需要A~1..B），如果有任何冲突，git不会像rebase那样自动继续（至少在1.7.3.1）。

先摘樱桃。。LAST仅适用于简单场景。

为了实现一个体面的“将其合并到集成分支中”，同时对自动跳过已集成的拾取、移植钻石合并、交互控制等事情感到舒适……）最好使用重基。这里的一个答案指出了这一点，然而协议包括一个危险的git分支-f和一个临时分支。这里有一个简单的稳健方法：

git rebase -i FIRST LAST~0 --onto integration
git rebase @ integration

-i允许交互控制。如果LAST是分支名称，~0可确保分离的重基（不移动/另一个分支）。否则可以省略。第二个rebase命令只是以安全的方式将集成分支ref向前移动到中间分离的头部-它不会引入新的提交。要使用合并菱形等对复杂结构进行重基化，请考虑第一个重基中的--rebase merges或--rebase convers=rebase cousins。