Git - 如果我想拥有一致的工作流程，那么 cherry-pick 是一种不好的做法吗？

Question

<分区>

Answer 1

使用 git cherry-pick 是不错的做法。你用它做什么可能会也可能不会。许多事情都是如此。 git push -f --no-verify origin master 不好吗？如果您不小心或不知道自己在做什么，它可能会挽救您的生命或给您带来麻烦。

以下工作流程并不少见:

您在 develop 分支中实现，两周后您将代码发布给您的 Beta 测试人员。两周后，如果没有任何问题，您将测试版升级为生产版:

     develop --a--b--c--d
                         \
release-beta -------------d'
                           \
release-prod ---------------d''

这种情况一直持续下去，直到有一天在生产中发现问题...幸运的是，在您的 develop 分支中提交 f 将修复它。

您有几个选择:

您可以将 develop merge 到 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 解决了一个生产问题，但又造成了另一个问题!如果您在一次提交中交付代码和测试，这本可以避免。

---

以我的拙见，没有根本性的不良做法；您只能评估在给定情况下您的选择是什么。知道哪些是最好的来自实践和经验。没有 Elixir 。

这可能不是您想要的答案:git cherry-pick 是不错的做法。如果您知道如何和何时使用它，它就是一个有用的工具。