Git - 如果我想拥有一致的工作流程，挑选樱桃是一种不好的做法吗？

Question

我发现cherry-pick在某些情况下特别有用，例如，当我有一个feature1分支和一个test-feature1分支时，我想应用测试中发现的更正；或者换句话说，我想测试新功能，为此我需要在测试分支中使用这些新功能。

cherry-pick这里的好处是我可以选择我想在其他分支中应用的具体更改；也许合并整个分支并不有趣。

我在过去的项目中一直在使用它，但我认为这种做法会导致工作流程不一致。是cherry-pick-ing一个不推荐和可避免的做法？

Answer 1

根据我的经验，樱桃采摘是不可取的，原因如下：

- 挑选是一个信号，您将要做一些不属于正常代码流的事情，因此将其视为“您自担风险”

1）

在正常的日常使用中，您应该避免随机引入来自其他功能分支的提交，因为如果某些代码尚未到达主分支（dev、master、trunk - 取决于您的分支策略），那么很可能该代码没有到达主分支足够成熟。它尚未通过合并请求，尚未经过代码审查人员等的验证。

因此，当你引入一些外国代码时，你就要对其负责。

当您稍后创建合并请求以将分支集成到主分支中时，代码审阅者会将所有代码视为您的代码。然后你就得找借口“是的，但这不是我的代码，是同事写的，我只是借用的”。决不。你现在要对此负责。

而且，稍后当相同的代码作为来自原始分支的合并请求进入时，它必须由某人进行审查。现在，相同的代码已被验证两次。这是浪费时间。

要有耐心，等待某些功能变得稳定并到达主分支，以便您可以将其拉入您的分支而无需承担责任。

2）

有时，在某些情况下，你会被某人强迫去进行挑选。例如，一些经理说：“我们现在需要该分支的此修复程序，但我们不需要任何其他更改；请选择它并将其合并到我们新的修补程序分支中”。然后就成为他们的决定以及处理后果的责任。向他们明确表示他们违反了您的正常代码流程。

将紧急修复从 dev 挑选到 master 的另一种方法是从最后发布的标签创建一个新的修补程序分支，修复那里的问题，测试它，发布修补程序，然后将修补程序合并到 dev 中。

为什么这样？因为如果您首先在开发中修复问题，然后将其挑选到主控中，则存在开发分支进行一些关键代码更改而导致修复与主控不兼容的风险。因此，在精挑细选之后，您可能最终会专门针对 master/release 分支重写整个修复程序。

我已经多次遇到这种情况（哦，我只是从开发人员那里挑选这个修复程序......废话，它甚至没有建立在我非常紧急的修补程序分支上，必须重写它）。

项目经理希望尽快发布修补程序，他们通常不太关心开发分支。因此，更有意义的是基于稳定版本（主）分支实现修复，发布修补程序，然后将其合并回主开发分支（同样，可能必须重写修复程序，因为它与最新的更改不兼容）开发）。

Answer 2

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

以下工作流程并不少见：

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

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

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

您有几个选择：

您可以合并develop到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在于，它将暴露您在制作小型、自给自足的变化单位方面的好坏。

考虑这个场景：

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

但是你在两个单独的提交中提交这两个文件......

123abc fix: implement foo function to fix issue in production
456fgh fix: implement tests for foo function

在某些测试框架中，.todo注解会自动使您的测试运行失败，以提醒您仍然需要实现测试……太棒了！所以你的develop分支失败了，但你知道为什么。

还记得f上面那个提交吗？原来它只包含代码而不包含测试......所以当你在release-prod分支中运行你的测试时没有任何失败......因为那个提交没有引入失败的测试！

但事情变得更糟......提交f修复了一个生产问题，但创造了另一个！如果您在一次提交中交付代码和测试，则可以避免这种情况。

在我看来，没有根本的坏习惯；您只能评估在特定情况下您的选择。知道哪些是最好的来自实践和经验。没有银弹。

这可能不是您想要的答案：git cherry-pick这不是坏习惯。如果您知道如何以及何时使用它，它就是一个有用的工具。