Using git cherry-pick这并不是一个坏习惯。你用它做什么可能是也可能不是。对于很多事情来说都是如此。是git push -f --no-verify origin master坏的？如果您不小心或不知道自己在做什么，它可能会挽救您的生命或给您带来麻烦。
以下工作流程并不少见：
您在develop分支，两周后您向 beta 测试人员发布代码。两周后，如果没有任何进展，您可以将测试版升级为生产版：
develop --a--b--c--d
\
release-beta -------------d'
\
release-prod ---------------d''
这种情况一直持续下去，直到有一天在生产中发现一个问题……幸运的是，提交了f在你的develop分支会修复它。
您有几个选择：
你可以合并develop into release-beta，快速跟踪 Beta 测试周期并立即发布到生产环境。问题是您可能会也可能不会过早地发布代码。您的 Beta 测试人员可能没有机会发现一些讨厌的错误。
或者你可以直接挑选f到release-prod分支，运行测试并发布到生产环境（如果您对结果感到满意）：
+---- hot fix
|
v
develop --a--b--c--d--e--f--g
\ \
release-beta -------------d' \
\ \
release-prod ---------------d''---f'
的诅咒（或祝福）git cherry-pick是它会暴露出你在进行小的、独立的变革单位方面做得有多好或多坏。
考虑这种情况：
// foo.js
function foo() {
...
}
// foo.test.js
test.todo('foo does something awesome', () => {
// TODO
})
但是您在两次单独的提交中提交这两个文件......
123abc fix: implement foo function to fix issue in production
456fgh fix: implement tests for foo function
在一些测试框架中，.todo注释将自动使您的测试运行失败，以提醒您仍然需要实施测试...太棒了！所以你的develop分支失败，但你知道为什么。
记住那个提交f多于？事实证明它只包含代码而不包含测试......所以当你在release-prod分支没有失败...因为该提交没有引入失败的测试！
但事情变得更糟......提交f修复了一个生产问题，但又造成了另一个问题！这could如果您在一次提交中交付代码和测试，就可以避免这种情况。
以我的拙见，没有什么根本性的不良做法；您只能评估在特定情况下您的选择是什么。知道哪些是最好的来自实践和经验。没有灵丹妙药。
这可能不是您想要的答案：git cherry-pick这并不是一个坏习惯。如果您知道的话，这是一个有用的工具how and when使用它。
