按规则分支时master分支的目的

Question

从“ 源代码管理正确完成”中 ：

只需单击一下“创建分支”按钮，就有许多种方法可以错误地分支您的代码库。 但是只有两种正确的策略–按规则分支和按异常分支–两者都与隔离发行版更改有关。 因此，应该始终通过其相应的发行版号来标识分支。

原因很简单：只有一个主干（主干，根目录，父级或您要调用的主干），并且该主干下的代码要么是生产中的产品（最后部署的版本），要么是稍后投入生产（下一个计划发行）。 这意味着您要么总是分支，要么有时只是分支。

• 按例外分支策略：

• 按规则分支策略：

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

因此，在使用按规则分支策略时，使用master分支的目的是什么？ 在我看来，master分支仅对一次具有单个发行版本且例外情况更高的软件产品有意义，也就是说，在使用异常分支策略时。

---

* CPython解释器的Github存储库是使用按规则分支策略的示例。

Answer 1

使用master分支的目的是什么？

在Git中，按照惯例， master是克隆后签出的默认分支（您可以更改，但是在这里，让我们假设远程仓库以'master'作为默认分支）

因此，使用master的目的是：克隆回购协议时，您希望供稿人（世界上任何对您的回购协议具有读取权限的人） 看到什么。
它可以是最新的主要发行版本，也可以是最新的开发状态：它取决于您在README或“ 存储库贡献者指南 ”中所描述的内容 。

Answer 2

这个问题没有一个普遍的真实答案，因为它基于近十年前建议仅使用两种分支策略的主观文章。 请注意，那个时候SVN仍然是国王，并且在那里创建分支机构非常昂贵-因此，没有多少人只是因为他们想要这样做而考虑使用很多分支机构（但是有些人这样做了）。

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

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

回答问题：

使用按规则分支策略时，使用master分支的目的是什么？ 在我看来，master分支仅对具有单个发行版的软件产品有意义。

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

但是，即使使用并行版本，仍需要模型master 。 它是您开发的所有功能的稳定分支。 它的用法很少但很重要-当产品经理决定开始开发一套新功能时，它是新版本的起点。 这也是您的策略应要求将已发布的分支定期合并回master -大概是在每次发布之后。 与图片相反，合并到master不会终止这些分支的生命。 相反，这将是同步的改进，以使master保持最新状态，并继续作为进一步开发迭代的适当来源。