有生产分支机构还是使用母版？

我与其他远程开发人员一起在Rails应用程序上与小型团队合作。我们开始修改我们的git工作流程。我们已经考虑过如下所示的分支结构：

(dev) -> (qa) -> (stag) -> (master)

但是，一些开发人员认为，对于新开发人员而言，他们可能会自动将其推送到master上，这可能会减少混乱。他们反而想让每个人都在master上工作，并为生产创建一个单独的分支。

(master) -> (qa) -> (stag) -> (prod)

有人告诉我您要保持master的可部署性，而不是将其用作开发，并且从我曾经工作过的地方开始，master总是可以为生产而部署。

使用分支结构（其中主动使用master进行开发，而使用单独的prod分支进行部署）会带来哪些不利呢？

这种方法既没有优势也没有劣势。我说这很简单的原因：对于Git，从母版进行开发或从母版发布都没有什么区别。您甚至不需要释放分支；您可以标记任意提交并释放它。

这里真正的麻烦是过程和过程之一。更高级的开发人员担心以一种方式进行操作会使新的开发人员感到困惑，因此需要准备投入一些时间来解释发布模型是什么以及这样做的原因。

只要所有人都知道master是用于开发的，而其他任意分支是用于发行的，并且维护它的工作已经完成，那么这种方法应该不会有任何问题。

我可以看到你的困境。我也有，直到我不了解我一直以来对大师的看法。

有人告诉我您要保持master的可部署性，而不是将其用作开发，并且从我曾经工作过的地方开始，master总是可以为生产而部署。

从Git的文档/书籍-Git分支

Git中的“ master”分支不是特殊分支。就像其他任何分支一样。几乎每个存储库都有一个唯一的原因是git init命令默认创建了它，并且大多数人都不会去更改它。

因此，如果您有首选的工作流程，并且很难使用它，因为团队中的不同开发人员对的想法也不同master。您甚至可以考虑重命名master以说prod和使用如下工作流程-

(dev) -> (qa) -> (stag) -> (prod)

这是更改主分支名称的方法。

我并不是说您必须更改master分支名称。但是，如果您有首选的工作流程并且有助于更改master分支名称，请通过各种方式进行:-)

在这种情况下，我更喜欢检查而不是约定。每个团队中的成员都擅长于启动新功能，而其他成员则更擅长于稳定发布内容。

如果您缺乏后者，那么代码审查会有所帮助（通常，纪律严明的人们还是希望代码审查）。

这就是为什么我们将Git存储库（我们使用的是Gitlab）配置为仅某些人可以合并请求请求，而每个开发人员都可以拥有自己的主存储库私有分支。

那解决了两个问题：

1. 新开发人员无法更改错误的分支（因为他们无法将其工作直接推入主存储库）。他们可能会master自己推送回购协议，但在请求请求到来时会解决。

2. 代码约定迅速在团队中传播，因为每次提交都至少要由另一个提出观点和知识的人来检查。

这完全取决于整个软件开发过程。在不了解整个过程的情况下，无法定义配置管理以及如何创建新版本。

有一个“敏捷”派系会选择“始终在工作的第一提交区域”。他们将不断对该区域进行自动化的构建和测试设施，并尝试“始终”使用工作系统。

他们会认为（master）->（release）可能具有1,2个中间步骤组织。

然后是更“经典”的派系，其流程由计划和计划的集成步骤驱动，以实现里程碑，其中“工作单元”发布是计划活动，其要求诸如“仅在（单元）经过测试时发布”并适合下一个计划的里程碑”。那里的计划包括“工作单元”的版本控制，通常，它们会花很多精力来定义下一个计划的产品发布在功能和修复方面的外观。为了进行计划，他们想知道开发人员发布的内容是“正确的”，并且有意识地提交工作单元。

这种经典方法并不一定意味着在更长的时间内没有完整的产品可用。

因此，“经典”工作流程将是：（开发）->（单元）->（集成）->（测试/质量检查）->（生产）。

集成商的作用是“接受/购买”已发布的单元，或者在它们不符合下一个即将发布的版本的情况下拒绝它们。

另外，也可以将这两种基本方法适当地混合使用。

根据我的经验（主要是在使用“经典”方法的领域），“经典”方法在团队中大约4-50个人的项目中表现良好。