摘樱桃后git如何合并？

假设我们有一个master分支。

然后我们创建一个 newbranch

git checkout -b newbranch

并向以下两个新提交newbranch：commit1和commit2

然后我们切换到主人 cherry-pick

git checkout master
git cherry-pick hash_of_commit1

调查gitk我们发现，commit1及其精选版本具有不同的哈希值，因此从技术上讲，它们是两个不同的提交。

最后，我们合并newbranch为master：

git merge newbranch

并看到这两个具有不同哈希值的提交没有问题地合并在一起，尽管它们暗示应该将相同的更改应用两次，所以其中之一应该失败。

git真的在合并时对提交内容进行了智能分析，并决定不应两次应用更改，或者这些提交在内部被标记为链接在一起吗？

简短答案

不用担心，Git会处理的。

长答案

与例如SVN ¹不同，Git不会以增量格式存储提交，而是基于快照的^2,3。SVN会天真地尝试将每个合并的提交作为补丁来应用（并且由于您所描述的确切原因而失败），但是Git通常能够处理这种情况。

合并时，Git将尝试将两个HEAD提交的快照合并到一个新的快照中。如果两个快照中的代码或文件的一部分相同（即，因为已经选择了提交），则Git不会使用它。

资料来源

¹ Subversion中的Skip-Deltas
² Git基础知识
³ Git对象模型

合并之后，您可能会两次在历史记录中进行精心挑选的提交。

为防止这种情况的解决方案，我在文章中引用了这篇文章，该文章建议具有重复（樱桃精选）提交的分支在合并之前使用rebase：

git cherry-pick之后的git merge：避免重复提交

想象我们有一个master分支和一个b分支：

   o---X   <-- master
    \
     b1---b2---b3---b4   <-- b

现在我们迫切需要master中的提交b1和b3，而不是b中的其余提交。因此，我们要做的是检出master分支，然后执行pick-pick提交b1和b3：

$ git checkout master
$ git cherry-pick "b1's SHA"
$ git cherry-pick "b3's SHA"

结果将是：

   o---X---b1'---b3'   <-- master
    \
     b1---b2---b3---b4   <-- b

假设我们对master进行了另一次提交，我们得到：

   o---X---b1'---b3'---Y   <-- master
    \
     b1---b2---b3---b4   <-- b

如果现在将分支b合并到master：

$ git merge b

我们将得到以下内容：

   o---X---b1'---b3'---Y--- M  <-- master
     \                     /
      b1----b2----b3----b4   <-- b

这意味着b1和b3引入的更改将在历史记录中出现两次。为避免这种情况，我们可以重新设置基础，而不是合并：

$ git rebase master b

这将产生：

   o---X---b1'---b3'---Y   <-- master
                        \
                         b2'---b4'   <-- b

最后：

$ git checkout master
$ git merge b

给我们：

   o---X---b1'---b3'---Y---b2'---b4'   <-- master, b

编辑 大卫·柠檬的评论所建议的更正