合并有时会很困难，只需创建一个补丁并手动应用更改即可。

创建从start_commit到end_commit的修补程序文件。git diff<start_commit><end_commit>>patch.diff签出分支并手动应用修补程序中的更改。

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

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

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

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

假设您有2个分支，

“branchA”：包括要复制的提交（从“commitA”到“commitB”

“branchB”：要从“branchA”转移提交的分支

1)

 git checkout <branchA>

2） 获取“commitA”和“commitB”的ID

3)

git checkout <branchB>

4)

git cherry-pick <commitA>^..<commitB>

5） 如果您有冲突，请解决并键入

git cherry-pick --continue

继续樱桃采摘过程。

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

git cherry-pick <commit> -n

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

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

先摘樱桃。。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。

我将VonC的代码打包成一个简短的bash脚本gitmulticherry-pick，以便于运行：

#!/bin/bash

if [ -z $1 ]; then
    echo "Equivalent to running git-cherry-pick on each of the commits in the range specified.";
    echo "";
    echo "Usage:  $0 start^..end";
    echo "";
    exit 1;
fi

git rev-list --reverse --topo-order $1 | while read rev 
do 
  git cherry-pick $rev || break 
done 

我目前正在使用这个方法来重建一个项目的历史，该项目在同一个svn主干中混合了第三方代码和定制。我现在正在将核心第三方代码、第三方模块和定制拆分到各自的git分支上，以便更好地理解未来的定制。gitcherry-pick在这种情况下很有用，因为我在同一个存储库中有两棵树，但没有共享的祖先。