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

Question

由于我们公司当前面临一些问题，因此我们需要改进 Git 流程设置。

我们当前的生命周期：

• 我们从一个存储库为多家公司编码白标产品
• 每天 20 多个开发人员代码 ~30 个拉取请求（我们使用 Github）
• 我们将所有代码推送到master分支
• 每两周我们release/2018-xx都会创建master
• 该版本已由五家公司测试和使用
• 他们都在接下来的几周内向我们报告了错误
• 我们将这些错误合并master并挑选出来release/xx
• 每当每个公司决定时，他们就会投入release/xx生产
• 当他们部署时我们摧毁

我们面临的问题：

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

master2）我们每天必须挑选超过 20 个修复程序release/2018-xx并修复大量冲突（另一种方法是从发布分支分支修复错误，但我们会在主分支中遇到冲突）

有什么办法可以处理这么大的流量吗？

Answer 1

高层考虑

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

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

鉴于这两件事，您需要确定：

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

选择发布周期和版本控制方案时，您要考虑的主要权衡是：

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

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

版本控制方案

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

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

这三个版本都是数字和点组合而成。{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 的代码

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

注意：没有破坏分支。当您不断向它们添加错误修复时，这些分支会一直存在。

发布补丁

现在我们有了分支，假设 1.1.2 中有一个错误。您将把修复程序放入release-1.1 分支中。在release-1.1分支和产品的release 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。

发布主要功能

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

• 当一切准备就绪后，创建一个名为release-2.0的新分支。
• 在分支上进行 QA 并修复错误。将修复提交到release-2.0，并挑选它们来掌握（如果仍然适用）。
• QA 完成后，向客户发布 2.0.0 版本。

发布周期

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

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

• 可以根据需要频繁发布补丁，为客户修复错误。前任。日常的。
• 小版本可以每 1 - 4 个月进行一次
• 主要版本发布可以每 1 - 2 年进行一次

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

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

结论

还有很多极端情况和需要考虑的事情，但这是对需要考虑的事情的一个很好的概述。希望能帮助到你。