GitHub上的版本化分支是什么？

在GitHub上，有时我会看到项目除了标记之外还有“1.x”和“2.x”分支。以美国为例。它有一个

master

和

1.x

分支，以及几个标记

这让我好奇：

• 这些“1.x”和“2.x”（等）“版本分支”将在什么时候创建？在什么时候它们会与

  master

  合并
• 从这些“版本分支”在什么时候构建工件？换句话说，“1.x”可能意味着“1.0.0”或“1.5.29”……但最新版本可能是“1.7.14”。“1.x”分支和二进制文件的“1.7.14”版本（JAR、ZIP等）之间有什么关系
• 如果您已经准备使用“版本分支”，那么标签可能有什么用途

---

下面简要介绍分支和标记的工作原理以及如何最好地使用它们
1。分支机构
分支提供了一种将代码划分为不同开发流的方法。最初，您从一个主分支开始（可以是

master

、

trunk

或其他常用名称）。随着项目的发展，您在开发时开始需要一定的稳定性
保证这一点的一个好方法是开始在工作中使用多个分支。考虑下面的内容：你正在开发一个开发项目将是高和/或长期的特性。如果它会改变当前现有代码的行为，那么您不希望在主分支中使用它，因为当它正在工作时，您可能会为其他人破坏一些东西。所以，这是您通常创建特性（或主题）分支的时候。当您的代码变得足够稳定时，您可以将您的特性分支与相应的主代码合并。这种方法帮助您独立于其他开发人员工作。他们可以检查您的工作并对其进行评论，提出修复方案，同时让您的

主机保持稳定

2。标签

标签被认为是永久性的。它们是给定时间点上代码的标记。当您发布版本
1.2.3
时，如果有人报告错误，您需要能够准确地告诉此版本中的内容，以便您能够轻松地复制错误，并在发布较新版本后的开发阶段检查是否已解决问题

3。使用分支机构并从分支机构中释放

假设您有多个客户。假设
ClientA
与您签订了一份合同，他们将支付使用
1.2.3版本的费用，而
ClientB
是一个新客户，对您在
2.x
版本中的一些功能的开创性工作感兴趣，而
ClientA
并没有大肆宣传，因此不太愿意升级到。您的合同规定，每个客户在支付许可证费用后一年内获得服务。是的，一般来说，公司应该推动其客户升级到其产品/服务的更新版本，但客户往往是大型机构，其工作和决策的速度远远慢于预期

因此，为了能够支持这两个客户机，您需要确保您有一个适当的分支策略，并且能够独立工作。这通常意味着您有一个像master这样的主要分支，所有的前沿开发都是在这个分支上完成的。当某些功能准备就绪时，如果这些客户机的各个分支上需要这些功能，它们将合并到各自的分支中。因此，如果您在
master
上开发了
feature-15
，并且它是
ClientB
所需要的，那么您只需将它合并到它们的分支。如果
ClientA
报告了一个关键问题，该问题似乎只与他们的产品版本相关，并且在以后的版本中不可复制，那么您可以仅为他们应用修复程序并推出一个版本

通常情况下，你的合同是这样的，你不会给你的客户某些功能，除非他们已经为此付费。您的定价模式可以是年度服务，包括全年免费升级，包括次要和主要版本。您还可能有一些几年前签署的客户机，这些客户机的升级速度非常慢，因此需要将不同的版本行保持更长的时间

3.1。多分支环境中的分支和标记

假设您有以下分支：


master
：最新发展（3.x）

1.x
：适用于坚持使用旧版本代码的客户

2.x
：用于更新一点的客户端


分支
1.x
将用于发布
1.x-SNAPSHOT
-s
2.0
用于
2.x-SNAPSHOT
和master——用于您在3.x上尚未发布的工作。通常情况下，对于您积极支持的每个主要版本都有一个分支是一个好主意。对于未成年人，您将分支该分支（例如，版本2.0.3将分支
2.0.x
）。当您在给定的特性迭代上的工作被认为已经完成且足够稳定时，您将为正在开发的版本创建一个分支标记，并将当前开发的版本切换到下一个次要版本。我说的是抽象的，因为您没有提到您正在使用的构建工具。例如，对于Maven，当前正在开发的版本将是一个
快照
，如果您当前发布的版本来自branch
2.x
，而您的开发版本是
2.3-SNAPSHOT
，然后，您的新发布版本将是
2.3
，下一个开发版本将是
2.4-SNAPSHOT

我希望这一切现在变得更有意义。
首先
1.x
分支是techn