在这些场景中使用git cherry-pick是否正确？

Question

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

情景一

在这里，我们有一个master，fix和develop分支。在我们对fix进行分支后，我们将版本号更新为1.0.1。我们对develop执行了相同操作，并将版本号更改为1.1.0。

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

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

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

场景2

如果术语不正确，或者我的图表没有意义，我再次道歉。这是我能描述的最好的。

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

大约在同一时间，其他人将develop，F1和F2修复了F3分支，但是以交错的方式（{{1}在fix之前提交了F1，H1之前提交了H2。现在，F3工作的人想要同步，所以他运行fix ，这使得这些变化有序。我们也假设没有冲突。

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

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

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

Answer 1

情景一

  

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

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

git cherry-pick F1..F3

如果是这样，那没关系。或者，您可以创建一个临时分支和rebase：

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

您实际上并不需要创建分支，因为您可以直接使用SHA-1，或者使用reflog，但是，为了简化起见，我使用了分支。

请注意git rebase基本上是一个美化的樱桃选择，所以在一天结束时它会做同样的事情。

情景二

  

如果他在提交F1时使用git cherry-pick并提交一系列提交，并以F3提交结束，会发生什么？那些合并会被忽略吗？

你可以告诉cherry-pick忽略与--no-merges的合并，因此合并提交本身将被忽略（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一段时间，看看它是如何转变的进行。

Answer 2

情景1很好;事实上，樱桃挑选似乎是去那里的最好方式。

情景2更成问题。我还没有尝试过，但我怀疑git会对尝试樱桃选择合并提交有所了解。在这种情况下，我认为变基是最好的选择。在某些情况下，合并提交是很棒的事情，但在这种交错的情况下，它们会妨碍并且还会使修改图形变得非常复杂。 （当然，它就是这样，但是rebase可以让你逃脱。）