在樱桃挑选之后，git合并是如何工作的？
让我们假设我们有一个master分支。
然后我们创建一个newbranch
git checkout -b newbranch并向newbranch提交两个新的提交: commit1和commit2
然后我们切换到master并制作cherry-pick
git checkout master
git cherry-pick hash_of_commit1查看gitk，我们可以看到commit1和它精心挑选的版本具有不同的哈希，因此从技术上讲，它们是两个不同的提交。
最后，我们将newbranch合并到master中
git merge newbranch并看到这两个具有不同散列的提交被合并在一起没有问题，尽管它们意味着应该应用两次相同的更改，因此其中一个应该会失败。
git真的会在合并时对提交的内容进行智能分析，并决定更改不应该应用两次，或者这些提交在内部被标记为链接在一起吗？
回答 1
Stack Overflow用户
发布于 2017-07-07 16:50:35
在这样的合并之后，你可能会在历史中有两次精挑细选的提交。
为了防止这种情况的解决方案，我引用了article的话，它建议具有重复(樱桃挑选)提交的分支在合并之前使用rebase：
git cherry-pick之后的
git合并:避免重复提交
假设我们有一个主分支和一个分支b：
O-X <-- master \b1-b2-b3-b4 <-- b
现在我们迫切需要主分支中的提交b1和b3，而不是b中剩余的提交。所以我们要做的就是签出主分支，然后选择提交b1和b3：
$ git结账大师$ 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合并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签出主机$ git合并b
为我们提供了：
O-X-b1‘-b3’-Y-b2‘-b4’<-- master，b
编辑David Lemon的评论所假定的更正
https://stackoverflow.com/questions/14486122
复制相似问题