我过去经常摘樱桃，但发现我时不时会有一些神秘的问题。 我偶然看到在微软工作了25年的Raymond Chen的一篇博客，他描述了在某些情况下采摘樱桃可能会导致问题的场景。

经验法则之一是，如果您从一个分支选择到另一个分支，然后在这些分支之间合并，那么您迟早会遇到问题。

以下是Raymond Chen关于这个主题的博客:https://devblogs.microsoft.com/oldnewthing/20180312-00/?p=98215

雷蒙德的博客唯一的问题是他没有提供一个完整的工作示例。所以我会试着在这里提供一个。

上面的问题问的是如何将HEAD指向的提交合并到master。

以下是如何做到这一点:

找到master和a-good特性之间的共同祖先 分支。 从那个祖先创建一个新分支，我们称之为 新的分支补丁。 樱桃选择一个或多个提交到这个新的补丁分支。 将补丁分支合并到主和 一个较好的特性分支。 主分支现在将包含提交，主分支和优良功能分支也将有一个新的公共祖先，如果稍后执行进一步的合并，它将解决未来的任何问题。

下面是这些命令的示例:

git checkout master...a-good-feature  [checkout the common ancestor]
git checkout -b patch
git cherry-pick a-good-feature  [this is not only the branch name, but also the commit we want]
git checkout master
git merge patch
git checkout a-good-feature
git merge -s ours patch

值得注意的是，合并到a-good-feature分支的最后一行使用了“-s our”合并策略。这样做的原因是，我们只需要在一个良好的功能分支中创建一个指向新的公共祖先的提交，由于代码已经在该分支中，我们希望确保没有任何合并冲突的机会。如果您正在合并的提交不是最近的，这一点就变得更加重要。

围绕部分合并的场景和细节可能会非常深入，所以我建议阅读Raymond Chen博客的全部10部分，以充分理解可能出现的问题，如何避免它，以及为什么它会起作用。

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

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

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

Git签出版本

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

例如

git cherry-pick 634af7b56ec

第三步:git push

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

我过去经常摘樱桃，但发现我时不时会有一些神秘的问题。 我偶然看到在微软工作了25年的Raymond Chen的一篇博客，他描述了在某些情况下采摘樱桃可能会导致问题的场景。

经验法则之一是，如果您从一个分支选择到另一个分支，然后在这些分支之间合并，那么您迟早会遇到问题。

以下是Raymond Chen关于这个主题的博客:https://devblogs.microsoft.com/oldnewthing/20180312-00/?p=98215

雷蒙德的博客唯一的问题是他没有提供一个完整的工作示例。所以我会试着在这里提供一个。

上面的问题问的是如何将HEAD指向的提交合并到master。

以下是如何做到这一点:

找到master和a-good特性之间的共同祖先 分支。 从那个祖先创建一个新分支，我们称之为 新的分支补丁。 樱桃选择一个或多个提交到这个新的补丁分支。 将补丁分支合并到主和 一个较好的特性分支。 主分支现在将包含提交，主分支和优良功能分支也将有一个新的公共祖先，如果稍后执行进一步的合并，它将解决未来的任何问题。

下面是这些命令的示例:

git checkout master...a-good-feature  [checkout the common ancestor]
git checkout -b patch
git cherry-pick a-good-feature  [this is not only the branch name, but also the commit we want]
git checkout master
git merge patch
git checkout a-good-feature
git merge -s ours patch

值得注意的是，合并到a-good-feature分支的最后一行使用了“-s our”合并策略。这样做的原因是，我们只需要在一个良好的功能分支中创建一个指向新的公共祖先的提交，由于代码已经在该分支中，我们希望确保没有任何合并冲突的机会。如果您正在合并的提交不是最近的，这一点就变得更加重要。

围绕部分合并的场景和细节可能会非常深入，所以我建议阅读Raymond Chen博客的全部10部分，以充分理解可能出现的问题，如何避免它，以及为什么它会起作用。

如果你是新手，尝试GitHub桌面版本，当你选择选择选项时，GitHub会要求你选择你想要提交的分支。

1)

2)

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

例如:git选择d42c389f

Git -pick应该是你的答案。

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

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

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

就变成:

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

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

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

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