我不是开发人员。 在我们的一个项目中，由于很多工单需要时间才能完成，我们一直在挑选我们的提交，现在我们必须经常这样做。 一位开发人员告诉我，应该避免挑选樱桃，因为它会使存储库不稳定。 这是什么意思，它如何使回购不稳定？换句话说，采摘樱桃的负面后果是什么？
Git 挑选的一个典型用例是将提交从一个分支引入另一个分支，因为这样做的常用方法(例如通过合并或变基(不可用。 通常的合并选项可能不可用，因为功能分支尚未准备好合并到其源。 但是，可能需要立即在源分支中进行某些提交，例如对于错误或其他热修复程序，因此挑选樱桃是执行此操作的一种方法。
挑选樱桃并没有真正使存储库不稳定，但是这样做会冒到处重复提交的风险。 回到一个功能分支的例子，有一个需要立即回到源的提交，如果我们以后合并这个功能分支，那么我们可能会引入同一个提交。 因此，源分支最终可能会有多个提交，每个提交在功能上都应该做同样的事情。 这并没有真正使存储库不稳定，但它确实使历史记录难以阅读。 将来，历史记录的读者可能会发现很难弄清楚贡献者在做什么，从而产生了重复的提交。
这个问题的根源在于，Git cherry-pick 实际上会在每次使用时创建一个新的提交，并带有新的SHA-1 哈希。 因此，从功能分支到源代码中挑选单个提交实际上会给存储库留下两个提交，功能相同，但具有完全不同的 SHA-1 哈希。
需要明确的是，挑选樱桃不会损害您的存储库。Git 适合采摘樱桃。挑选可能会使您的代码不稳定。
樱桃选择基本上是将提交复制到另一个分支。仔细使用，这是一个非常有用的工具。草率地使用，您正在复制未经测试的代码。如果您发现自己不得不大量使用樱桃挑选，那么您的流程可能有些次优。
一个典型的例子是，当你有一个大型的功能分支，它也修复了一个错误。该功能需要很长时间才能完成，但您现在需要修复该错误。(更深层次的问题是为什么该功能分支需要这么长时间？是不是太大了？它可以切成一系列更小的特征吗？
您的存储库如下所示。
A - B - C - D - E [master]
1 - 2 - bugfix - 3 - 4 - 5 [feature]
接下来会发生什么取决于您的工作流程。你可以把它直接挑到master上。
git cherry-pick bugfix
A - B - C - D - E [master]
1 - 2 - bugfix - 3 - 4 - 5 [feature]
这具有将未经测试的代码直接提交到master的所有问题。这可能取决于其他一些feature。它可能只是不起作用。它可能会引入更微妙的错误。它可能不完整。这可能就是他们所说的"使代码不稳定"所指的。
最好遵循"功能分支"工作流。不允许直接提交到master。一切都必须在分支中完成。分支机构在合并之前要经过 QA。这可确保master始终保持已知的良好状态，并且没有人共享未经测试的低质量代码。
您将打开一个新分支以进行错误修复，然后挑选它。
git checkout -b fix/bug
git cherry-pick bugfix
bugfix' [fix/bug]
/
A - B - C - D - E [master]
1 - 2 - bugfix - 3 - 4 - 5 [feature]
然后fix/bug通过正常的 QA 流程运行。任何问题都已修复。当它通过 QA 时，它被合并到master中。假设有一个问题，所以有另一个提交。
git checkout master
git merge fix/bug
git branch -d fix/bug
bugfix' - F
/
A - B - C - D - E ----------- G [master]
1 - 2 - bugfix - 3 - 4 - 5 [feature]
现在feature应该从master更新自身，以确保它具有完整的错误修复。主版本的错误修复与其自己的错误修复版本之间可能存在冲突。照常修复它们。
git checkout feature
git merge master
bugfix' ---- F
/
A - B - C - D - E -------------- * [master]
1 - 2 - bugfix - 3 - 4 - 5 - * [feature]
然后，一旦feature完成，就可以像往常一样将其合并到master中。Git 不在乎历史记录中有两个版本的错误修复，任何问题已经在更新合并中得到解决。
git checkout master
git merge feature
git branch -d feature
bugfix' ---- F
/
A - B - C - D - E -------------- * --------- * [master]
/
1 - 2 - bugfix - 3 - 4 - 5 - * - 6 - 7
旁注：如果您不是合并而是使用rebase来更新您的分支，我的偏好是，如果 Git 认为它是多余的，它甚至可能会完全删除错误修复提交。
git checkout feature
git rebase master
bugfix' - F
/
A - B - C - D - E --------- - * [master]
1 - 2 - 3 - 4 - 5 [feature]