前面的答案描述了如何将特定提交的更改应用到当前分支。如果这就是你所说的“如何合并”，那么就按照他们的建议进行选择。

但是如果你真的想要合并，也就是说，你想要一个有两个父节点的新提交——当前分支上现有的提交，以及你想要应用更改的提交——那么选择是不能实现的。

拥有真实的合并历史可能是可取的，例如，如果您的构建过程利用git祖先来根据最新标记自动设置版本字符串(使用git describe)。

而不是选择，你可以做一个实际的git合并-不提交，然后手动调整索引，删除任何你不想要的变化。

假设你在分支A上，你想合并分支B顶端的提交:

git checkout A
git merge --no-commit B

现在，您已经准备好创建一个带有两个父类的提交，即a和B的当前提示提交。然而，您可能应用了比您想要的更多的更改，包括来自B分支早期提交的更改。您需要撤消这些不需要的更改，然后提交。

(可能有一种简单的方法可以将工作目录的状态和索引设置回合并之前的状态，这样您就可以在一个干净的石板上选择您想要的提交。但我不知道怎样才能重新开始。git checkout HEAD和git reset HEAD都将删除合并状态，违背了此方法的目的。)

因此，手动撤消不需要的更改。例如，你可以

git revert --no-commit 012ea56

对于每个不想要的提交012ea56。

当你完成调整时，创建你的commit:

git commit -m "Merge in commit 823749a from B which tweaked the timeout code"

现在您只有想要的更改，并且祖先树显示您从技术上合并了B。

在我的用例中，我们对CI CD有类似的需求。 我们使用git流来开发和master分支。 开发人员可以自由地将他们的更改直接合并到开发中，或者通过来自功能分支的拉请求进行合并。但是为了master，我们通过Jenkins以自动的方式合并来自开发分支的稳定提交。

在这种情况下，做樱桃选择不是一个好的选择。然而，我们从commit-id创建一个本地分支，然后将该本地分支合并到master并执行mvn清洁验证(我们使用maven)。如果成功，则使用maven发布插件，使用localCheckout=true选项和pushChanges=false将产品版本工件发布到nexus。最后，当一切都成功时，再将更改和标签推到原点。

示例代码片段:

假设您是在主，如果手动完成。然而在jenkins上，当你签出repo时，你将在默认分支上(如果配置为master)。

git pull  // Just to pull any changes.
git branch local-<commitd-id> <commit-id>  // Create a branch from the given commit-id
git merge local-<commit-id>  // Merge that local branch to master.
mvn clean verify   // Verify if the code is build able
mvn <any args> release:clean release:prepare release:perform // Release artifacts
git push origin/master  // Push the local changes performed above to origin.
git push origin <tag>  // Push the tag to origin

这将给你一个无所畏惧的合并或冲突地狱完全控制。

如果有更好的选择，请随时提出建议。

我们将不得不使用git cherry-pick <commit-number>

场景:我在一个名为发布的分支上，我只想从主分支添加一些更改到发布分支。

步骤1:签出您想要添加更改的分支

Git签出版本

步骤2:获取你想要添加的变更的提交号

例如

git cherry-pick 634af7b56ec

第三步:git push

注意:每次合并都会创建一个单独的提交号。不要为不能工作的合并取提交号。相反，是你想添加的任何常规提交的提交号。

假设你想合并提交e27af03从分支X到主分支。

git checkout master
git cherry-pick e27af03
git push

Git -pick应该是你的答案。

应用现有提交引入的更改。

不要忘记阅读bdonlan在这篇文章中关于择优选择后果的回答: “从一个分支中提取所有提交，将指定的提交推到另一个分支”，其中:

A-----B------C
 \
  \
   D

就变成:

A-----B------C
 \
  \
   D-----C'

这个提交的问题是git认为提交包含了它们之前的所有历史

其中C'有不同的SHA-1 ID。 同样地，从一个分支向另一个分支选择提交基本上涉及生成一个补丁，然后应用它，因此也会丢失历史记录。

这种提交id的改变破坏了git在其他事情之间的合并功能(尽管如果谨慎使用，有一些启发式方法会掩盖这一点)。 更重要的是，它忽略了函数依赖关系——如果C语言真的使用了B语言中定义的函数，你永远不会知道。

您可以使用git自行选择将单个提交应用到当前分支。

例如:git选择d42c389f