在这些情况下使用 git cherry-pick 是否正确？答案

【问题标题】：Is it right to use git cherry-pick in these scenarios?在这些情况下使用 git cherry-pick 是否正确？
【发布时间】：2014-07-08 02:04:48
【问题描述】：

如果我的符号或术语有误，我深表歉意。我在个人项目中使用git 已经有一段时间了，并且不必处理复杂的合并场景。我们开始在工作中使用它，并且遇到了更复杂的场景。我仍然是git 新手，所以我想找出樱桃采摘的最佳做法。

场景一

在这里，我们有一个 master、fix 和 develop 分支。在我们分支fix 之后，我们将版本号更新为1.0.1。我们对develop 做了同样的事情，并将版本号更改为1.1.0。

假设修复F1、F2 和F3 已提交给fix。其中，我们关心修复F2 和F3，但不关心F1，因为它是对已弃用功能的更改。我们也不关心版本号更改为1.0.1。

现在我们可以毫无问题地将这些更改从fix 合并回master。但是如果我想将这些更改合并到develop 中呢？现在我正在使用git cherry-pick 来挑选F1 和F2。此外，对于大量提交，我正在使用一系列提交来挑选，这似乎工作正常。这是最好的做事方式吗？

这让我想到了关于 git cherry-pick 的下一个场景：

场景 2

再次，如果术语不正确，或者我的图表没有意义，我深表歉意。这是我能形容的最好的了。

所以在这种情况下，除了上述分支之外，我们还有一个 hotfix 分支。假设有人将修补程序 H1 和 H2 提交到 hotfix，然后将这些更改合并到 master、fix 和 develop。

大约在同一时间，其他人将修复 F1、F2 和 F3 提交到 fix 分支，但以交错的方式提交（所以 F1 在 H1 之前提交，并且H2 是在 F3 之前提交的。现在处理 fix 的人想要同步，所以他运行了一个 git pull，这会将这些更改按顺序排列。让我们也假设没有冲突。

现在，假设这个人想要将他的所有修复合并到develop。在这种情况下，如果他使用git cherry-pick 和一系列从F1 的提交开始，到F3 的提交结束，会发生什么？这些合并会被忽略吗？据我所知，您无法挑选合并（因为您需要指定主线）。那么在这种情况下，git cherry-pick 会直接忽略这些合并吗？

另外，为了不必处理这种情况，总是 rebase 而不是 git pull 是否更好，以便之后应用您的更改？这样你就可以指定提交的范围，它不会包括合并。

谢谢，如果我的问题很愚蠢或没有任何意义，我深表歉意。

【问题讨论】：

这个问题的意见如何？
你用什么来制作图形？
我使用了一个名为yEd的工具。它是免费的，而且非常好。

标签： git version-control merge rebase cherry-pick

【解决方案1】：

场景一

现在我正在使用 git cherry-pick 来挑选 F1 和 F2。

你的意思是F2和F3，对吧？基本上是这样的：

git cherry-pick F1..F3

如果是这样，那很好。或者，您可以创建一个临时分支并重新设置：

git checkout -b for-develop F3
git rebase --onto develop F1
git checkout develop
git merge for-develop

您实际上不需要创建分支，因为您可以直接使用 SHA-1 或 reflogs，但是，为了简化目的，我使用了一个分支。

请注意，git rebase 基本上是一个被美化的樱桃，所以最终它会做同样的事情。

场景二

如果他将 git cherry-pick 与从 F1 的提交开始到 F3 的提交结束的一系列提交一起使用会发生什么？这些合并会被忽略吗？

您可以使用 --no-merges 告诉cherry-pick 忽略合并，因此合并提交本身将被忽略（M1，M2），而不是提交本身（H1，H2）。由于您已经拥有那些可能会产生一些问题的“开发”。如果实现了git cherry-pick --skip，那将不是问题（我为此发送了补丁，但从未应用过）。

但您也可以告诉cherry-pick 忽略已经存在的提交：

git cherry-pick --no-merges --right-only --cherry-pick develop...F3

您可以尝试git log 使用相同的参数来查看哪些提交会被精心挑选。或者您可以自己指定它们：

git cherry-pick F2 F3

最后，你也可以使用git rebase了：

git checkout -b for-develop F3
git rebase --onto develop F1
git checkout develop
git merge for-develop

请注意，git rebase 将与我在上面放置的 cherry-pick 命令执行相同的操作，并且您可以在两种情况下使用相同的 git rebase 命令。您还可以在两种情况下使用相同的 git cherry-pick 命令（使用 --no-merges --right-only --cherry-pick）。如果存在冲突，特别是如果提交变为空（很可能已经应用），您可能会遇到一些麻烦，因为没有 git cherry-pick --skip。

使用git rebase 通常更安全，因为这是每个人都使用的，但如果你喜欢冒险，可以尝试一段时间git cherry-pick，看看结果如何。

【讨论】：

【解决方案2】：

场景 1 没问题；确实，樱桃采摘似乎是去那里的最佳方式。

场景 2 的问题更大。我还没有尝试过，但我怀疑 git 会尝试挑选合并提交。在这种情况下，我认为变基是你最好的选择。在某些情况下，合并提交是很棒的事情，但在这种交错的场景中，它们会妨碍您，并且还会使您的修订图变得异常复杂。（当然是这样，但是 rebase 可以让你摆脱它。）

【讨论】：