需要明确的是，挑选不会损害您的存储库。 Git 很擅长挑选。采摘樱桃可能会让你code不稳定。
樱桃选择基本上是将提交复制到另一个分支。仔细使用，这是一个非常有用的工具。如果使用不当，你就会复制未经测试的代码。如果您发现自己必须经常使用cherry-pick，那么您的流程可能存在一些次优的情况。
一个典型的例子是，当您有一个大型功能分支时，它也修复了一个错误。该功能需要很长时间才能完成，但您现在需要修复该错误。 （更深层次的问题是为什么该功能分支需要这么长时间？它太大了吗？可以将其分割成一系列较小的功能吗？）
你的存储库看起来像这样。
A - B - C - D - E [master]
\
1 - 2 - bugfix - 3 - 4 - 5 [feature]
接下来发生的事情取决于您的工作流程。你could樱桃直接摘下来master.
git cherry-pick bugfix
A - B - C - D - E [master]
\
1 - 2 - bugfix - 3 - 4 - 5 [feature]
这存在将未经测试的代码直接提交到的所有问题master。这可能取决于其他一些部分feature。这可能行不通。它可能会引入更多微妙的错误。它可能不完整。这可能就是他们所说的“使代码不稳定”。
更好的是遵循“功能分支”工作流程 https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow。没有直接承诺master被允许。一切都必须在一个分支中完成。分支在合并之前要经过质量检查。这确保了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]
Then 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]
Now feature应该从master以确保它具有完整的错误修复。错误修复的 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]
