如何为拥有多个版本的大公司设置正确的GIT流程

Question

我们需要改进Git流程设置，因为我们目前在公司面临几个问题。

我们当前的生命周期：

• 我们为一家公司的多家公司编写白色标签产品
• 每天20+ devs代码~30个拉取请求（我们使用Github）
• 我们将所有代码推送到master分支
• 我们每隔一周从release/2018-xx
创建master
• 此版本已由五家公司测试和使用
• 所有人都在接下来的几周内向我们报告错误
• 我们将这些错误合并到master并将它们分别编入release/xx
• 每当公司决定时，他们都会将release/xx投入生产
• 当他们部署我们销毁

我们面临的问题：

1）即使我们有一个“稳定”版本，其中我们只添加 错误修正，我们仍然为所有五家公司执行此操作，有时其中一个公司的错误修正会破坏另一个公司的功能（=＆gt; ;创建四个发布分支并将所有固定分配到所有五个中将非常耗时）

2）我们必须每天从master挑选20多个修复程序到release/2018-xx并修复很多冲突（替代方法是从发布分支中修改bug修复，但我们会面对冲突然后变成主人）

有没有办法处理这么大的流量？

Answer 1

高级别考虑因素

需要考虑这个问题的几个方面：

• 客户的期望。
• 产品功能集的稳定性。

鉴于您需要建立以下两件事：

• 发布周期。
• 版本控制方案。
• 分支策略。

在选择发布周期时，您正在处理的主要权衡是：版本控制方案是：

• 以他们期望的速度快速为客户提供新功能。 VS.释放功能足够慢，以免你的头部爆炸。
• 提供稳定的功能集。 VS.打破向后兼容性，对产品进行重大技术改进。
• 在很长一段时间内为客户支持特定版本。 VS.最大限度地减少必须支持的版本数量。

让我们首先深入了解版本控制方案，因为这是最简单的方案。在定义之后，我们可以讨论一个免费的分支策略，最后是一个满足您需求的发布周期。

版本控制方案

有一种定义明确的版本软件称为semantic versioning。语义版本控制背后的主要思想是软件版本由三部分组成：

• 主要版本
• 次要版本
• 补丁版

这三个版本是数字并与点组合。 {Major Version}.{Minor Version}.{Path Version}。

有效语义版本的示例是：1.0.0,2.1.0,11.1.133

主要版本

主要版本更改表示发生了向后不兼容的更改。具体来说，我们假设您的产品目前是1.0.0版。并且您决定进行一系列更改以删除功能或更改现有功能的工作方式，并且您希望发布此新版本。由于您进行的更改可能会破坏软件的现有用户，因此需要增加主要版本，以便新版本的产品为2.0.0。同样，如果您的更改不会破坏旧功能，那么当您发布下一版本的软件时，您可以保留相同的主要版本。

次要版本

次要版本更改表示已添加新功能，并且所有内容仍向后兼容以前的版本。所以，让我们假设您有一个1.0.0产品，然后添加一个新的按钮来做一些很酷的事情，但其他一切工作完全一样。那么产品的下一个版本应该是1.1.0。

补丁版

补丁版本更改表示已修复一个或多个错误。没有添加任何新功能，也没有更改现有功能。

用户解释版本

的方式

这些是用户选择版本的可能动机：

• 用户希望使用最新的最佳版本来启动新功能：然后用户将选择具有最高主要版本，次要版本和修补程序版本的已发布版本。
• 用户想要一些新功能，但他们不想要在产品中使用的任何内容进行更改：然后用户选择与主要版本相同的版本他们现在使用的版本，但他们寻找最高的次要和补丁版本。
• 用户希望修复错误并且不想冒重大升级的风险：在这种情况下，用户会查找与他们当前使用的版本相同的主要和次要版本的版本，但他们选择版本最高的版本。

分支策略

有一种非常常见的分支策略可以补充语义版本。一般的想法是，对于每个唯一的主要和次要版本对，您创建一个发布分支。例如，如果您有以下版本：

• 1.0.0
• 1.0.1
• 1.1.0
• 1.1.1
• 1.1.2
• 1.1.3
• 1.2.0

您将维护以下git分支：

• 释放-1.0
• 释放-1.1
• 释放-1.2

这些发布分支中的每一个都基本上具有与最新补丁版本对应的代码：

• release-1.0：具有1.0.1
的代码
• release-1.1：具有1.1.2
的代码
• release-1.2：具有1.2.0的代码

您还有一个主分支，其中包含正在开发的最新代码。

注意：没有分支的破坏。当你继续为它们添加bug修复时，这些分支会一直存在。

进行补丁发布

现在我们有了分支机构，让我们说1.1.2中有一个错误。您将把修复程序放入release-1.1分支。在版本1.1分支中将版本增加到1.1.3并释放产品的1.1.3。如果用户想要1.1.2版的最新错误修复，则必须升级到1.1.3。 注意：在这种情况下，您不会创建新分支。

进行次要功能发布

我们假设您正在努力添加一些新功能，而不是破坏向后兼容性。在您的功能准备就绪之前，请将您的提交推送到主分支。在主分支中完成功能后，请执行以下操作：

• 从master创建一个分支并将其命名为release-1.3（记住我们的上一个版本是1.2）。
• 在分支机构上执行QA并修复错误。如果仍然适用，请将修复程序提交给发行版1.3并将其选择为主文件。
• QA完成后，将1.3.0版发布给客户。

进行主要功能发布

假设您正在处理向后不兼容的重大更改（删除旧功能并更改现有功能的工作方式）。将您的提交推送到掌握，直到您认为一切都已完成。

• 当一切准备就绪时，创建一个名为release-2.0的主分支。
• 在分支机构上执行QA并修复错误。如果仍然适用，请将修复程序提交到release-2.0并将其选择为master。
• 完成QA后，向客户发布2.0.0版本。

发布周期

以上一切都很好，但你多久发布一次功能？你支持他们多久了？这取决于您的客户。

一些正常发布时间表的一些想法如下：

• 补丁发布可以根据需要频繁完成，以修复客户的错误。防爆。每日。
• 可以每1至4个月进行一次小型发布
• 主要版本发布每1 - 2年

您支持特定主要和次要版本对的时间取决于您的客户。它们是一个发展缓慢的企业，需要为特定版本提供至少4年的支持吗？如果是这样，您可以减慢Minor和Major版本的速度，以减少必须维护的版本数量。

他们是快速移动的初创公司吗？如果是这样，您可能只支持6个月或一年的特定主要和次要版本对，并要求用户升级到更高版本以获得支持。

结论

还有更多的角落案例和需要考虑的事项，但这是对要考虑的事情的一个很好的概述。希望它有所帮助。

Answer 2

• 如果五家公司要求产品具有相同的功能和特性，您可以从一个发布分支release/xx为五家公司提供相同的发布版本。
• 如果五家公司要求产品不具备所有相同的特性和功能（有些可能会有所不同），您应该使用五个不同的分支机构分别为五家公司提供发布版本。

根据您的工作流程，似乎所有五家公司的代码都相同。为此，您可以使用以下工作流程：

• develop分支：所有开发人员在此开发中开发并推送他们的代码。如果您没有此分支，请从master分支创建它。
• master分支：开发人员创建拉取请求以将develop分支合并到master分支。 QA团队（或其他人）可以测试并批准将develop分支合并到master。将develop分支合并到master分支后，master分支上的版本实际上已准备好发布。然后，您可以通过添加标记（例如git tag -a v1.0 -m 'release version 1.0'）来记录发布版本，也可以通过从release/xx分支创建发布分支master来记录发布版本。
• 发布分支机构：如果您使用release/xx来记录master分支机构的发布版本，则每次发布时都会将r elease/xx分支机构发送给五家公司。
• hotfix分支：如果需要修复错误，您可以从相关的hotfix分支创建release/xx分支。修复hotfix分支上的错误后，将hotfix分支合并到master进行测试。如果已准备好发布，则从release/xx分支为新版本创建新的master分支。
• 将develop分支更新到最新版本：每次发布新版本后，将master分支合并到develop分支，以便所有开发人员可以继续他们的最新工作版本

此外，还有a successful branching model，您也可以参考。