Git 最佳实践：单一分支还是多个分支？

Question

我目前与多名开发人员组成远程团队工作。我们来自不同的地方。有时候，或者大部分时间，我们会处理不同的任务，也有时候会处理相同的任务。

例如，如果我正在处理一个名为A的特性（在branchA上），而我的同事正在处理另一个名为B的特性（在branchB上），那么提交我们的工作应该采取什么最佳实践呢？

1. 将branchA合并到master分支，进行构建/测试/部署。 2. 将branchB合并到master分支，进行构建/测试/部署。

或者

从master的develop分支创建新的分支，并将branchA和branchB合并到其中，然后进行构建/测试。如果一切顺利，请执行步骤1和2，并将master部署到生产环境中。

我的意思是，使用develop是将多个分支中的特性合并到单个QA版本中的一种方法。

但是，使用develop分支会增加一个额外的分支需要维护，而且基本上又将相同的分支合并到主分支上。

对于您的公司/类似情况，有哪些适用的方法？是否有针对这些情况的最佳实践？

- Gandalf StormCrow

Answer 1

使用特性分支（branchA和branchB）是很好的实践方法。

一般来说，生产项目应该在staging/QA和production之间进行分离。无论您是在版本控制中还是使用系统包或其他方式进行分离，都取决于您的项目。

如果您选择在Git中将staging与production分离，我建议将master设置为开发树，将production设置为生产树。为什么？开发人员会习惯性地合并到master，所有文档都谈论了合并到master，不要反对它。

生产分支不是一个大的维护问题。主要是你将简单地合并到master，这些应该是快进的，这在Git中非常容易和便宜。您可能希望强制记录每次更新生产的合并，或者您可以使用标签。重要的是，从master合并到production只应由发布经理完成，而不是由随机开发人员完成（在小型商店中，开发人员可能也是发布经理）。

生产分支的另一个好处是记录热修补程序。如果出现生产紧急情况，而master尚未准备好生产，您可以直接提交热修补程序到production。然后，可以将该热修补程序从production中挑选回来，以进行适当的测试。

您可能希望有三个分支。master用于开发，staging用于QA，production用于生产。将master合并到staging中，并假定它通过了测试，则将staging合并到production中。这为QA提供了一个稳定的分支，而生产仍然是生产中所使用的内容。

您也可以使用标签实现此操作，具有可移动的staging和production标签，但这不如完整的分支灵活。Git中的标签只是不移动的分支，您需要移动这些标签。热修补程序和挑选很难在标签中进行，如果master重新基础，则会出现问题。

基本工作流程是... feature_branch <---> master --QA--> staging --Release Manager--> production 请注意，合并始终是单向的，除了特性分支和master之间。

生产紧急情况的工作流程是... staging + hot patch --Release--> production --cherry pick--> feature_branch ...然后从feature_branch开始正常流程。通过首先修补staging，您至少可以通过加快QA过程来运行它。热修补程序可能会导致下一个staging合并中的冲突，因此尽快通过开发获取适当的修补程序。

- Schwern

Answer 2

如果您想表示一个已经准备好进行QA的版本，git中惯用的方法是使用标签。而其他SCM工具（如ClearCase或Accurev）使用层次结构来表示开发/测试/发布阶段，但我在我的任何项目或团队中都没有需要这样做，也不预见会需要。Git分支的主要目的是实现并行性。如果唯一的并行性是在不同的开发工作之间，那么您的branchA和branchB分支应该足够了。

- Jordan Samuels

Answer 3

所有这些实践最终都指向一个目标——尽快将代码部署到生产环境或更普遍地说，发布产品的版本。你几乎从来不想干扰用于部署生产的master分支。一个干净和通过QA的功能分支就足以合并到主分支中，除非你正在进行一些基本的重构。

使用单独的develop分支，你不必担心开发人员仅为在生产环境上测试而进行无谓提交的风险。develop分支总是需要有一组提交来进行测试。在生产环境的master分支中改变标志或添加日志来进行调试并没有什么意义，对吧？你只需将提交放入develop分支并继续测试即可。但是，在主要的master分支中留下一个更干净的历史记录，只进行编码逻辑相关的提交。如果你想在代码部署后跟踪特定功能及其开发工作流程，你将会在master分支中看到更少且更有意义的提交。这将使团队更轻松地处理此类问题并节省时间。

此外，使用单独的develop分支，您无需担心在部署生产时开发人员提交代码。更不用说，使用单独的develop分支可以使QA的工作变得更加容易。

- gravetii