Git 按规则分支时主分支的用途

从文章中：

只需单击“创建分支”按钮，就可以看到 错误地分支代码库的方法太多了。但是有 只有两种正确的策略-按规则分支和按规则分支 例外——两者都与隔离版本中的更改有关。 因此，分支应始终通过其 相应的发行号

原因很简单：只有一个主干（主线、根、， 父级，或者你想叫它的任何东西），以及下面的代码 trunk要么是现在正在生产的产品（最后部署的版本）， 或稍后将投入生产的内容（下一个计划版本）。及 这意味着你要么总是分支，要么只是有时分支

• 按异常策略进行分支：

• 按规则分支策略：

当您必须并行维护一个软件产品的多个发布版本时（这是很常见的，除非您有一个软件即服务交付模型），按规则分支策略似乎是最合适的*。但在这种情况下，如果您在专用环境中连续部署每个发行分支的所有标记（例如，在2.2环境中自动部署所有2.2.x标记，在2.3环境中自动部署所有2.3.x标记），每个发布分支的所有标记也将自动合并到主分支中，因为主分支应该反映生产中的内容。如果不同发布分支的标记在时间上交错，这将导致合并冲突（例如，在上面的分支规则图中，如果使用了连续部署，则该标记序列将合并到主分支中：2.2.1、2.2.2、2.2.3、2.3.1、2.3.2、2.2.4、2.3.3、2.2.5等；但由于不使用连续部署，因此只部署每个发布分支的最后一个标记，并因此自动合并到主分支中。）e主分支，因此不存在此类问题）

因此，当使用按规则分支策略时，使用主分支的目的是什么？在我看来，主分支仅适用于一次只有一个发布版本的软件产品，也就是说，当使用按异常分支策略时，主分支才有意义

---

*下面是一个使用按规则分支策略的示例

使用

master

分支的目的是什么

在Git中，

master

是默认的分支，在克隆之后签出（您可以更改它，但是在这里，让我们假设远程回购的默认分支是“master”）

因此，使用

master

的目的是：在克隆您的回购协议时，您希望您的贡献者（世界上任何有权阅读您的回购协议的人）看到什么。

---

它可以是最新的主发布版本，也可以是最新的开发状态：这取决于您在

自述文件中描述的内容.
这个问题没有普遍正确的答案，因为它基于一篇主观的文章，大约十年前，这篇文章建议只使用两种策略进行分支。请注意，当时SVN仍然是一个王者，在那里创建分支的成本很高，所以没有多少人会因为想要而考虑使用大量分支（但有些人做到了）

从那时起，许多事情发生了变化，许多团队采用了其他策略——例如分支模型，这实际上成为了行业标准之一。在该策略中，所有分支都发生在
开发
分支之外，而
主控
仅用作稳定的备份

无论如何，^^^^^^只是为了解释，引用的文章不是法律，而是作者的观点。这篇文章可能是错误的或不完整的（好吧，它是不完整的，因为它不包括一年前建议的
git flow
）.如果你在那里看到一个问题-这可能确实是一个问题，而不是你缺乏理解

回答问题:

当使用按规则分支策略时，使用主分支的目的是什么？在我看来，主分支仅适用于具有单一发布版本的软件产品

是的，积极地使用
master
branch对于具有单一发布版本的产品最有意义。实际上，“软件即服务”（比如“网站”）是最好的模型。如果在您的产品模型中，不同版本的软件上可能同时有不同的客户，那么分支策略需要改进。在这种情况下，您需要提出更复杂的方案

然而，即使是并行版本，仍然需要
master
模型。它是一个稳定的分支，拥有您曾经开发的所有功能。它的使用频率不常见，但很重要-当产品经理决定开始开发一组新功能时，它是新版本的起点。这就是also您的策略需要定期将发布的分支合并回
master
的原因-大概是在每次发布之后。与此相反，合并到
master
不会结束这些分支的生命。相反，这将是一个同步的改进，让
master
保持最新状态并继续作为pr操作进一步开发迭代的源代码。
Git的分支名称不是永久性的（您可以随时重命名任何分支），不是全局性的（您的分支名称不需要与其他任何分支名称匹配），甚至不是必需的（您可以不处理任何分支）-因此，这些规则都不适用于一个存储库。但是，一个存储库确实使用分支名称与其他一些Git存储库进行通信，因此，无论“他们”是谁，只要他们要求您使用他们的名称方案，您就可能希望遵守这些规则。其他