Tfs 一个项目的多个发布版本的Gitflow策略

我正在为我的项目设计一个分支和合并策略（我们使用TFS）。Project计划有多个发布版本。目前，我们正在测试v1.0alpha并在v2.0中工作

该计划是：

• 在测试人员即将发出绿灯后，v1.0版将发布给一个客户端
• 版本1.1（已在开发中）将部署到5-6个客户端
• v1.2版将安装到数十个客户端
• 等等

我们将尝试将旧客户升级到最新版本，但由于项目和市场的性质，客户升级可能需要几个月（几年？）

我们希望使用标准的gitflow，但似乎更适合使用单一版本。我设计了一个简化的gitflow：

方法是：

• 如果客户希望修复bug，我们将在其版本的发布分支中修复它，他必须升级到其版本的最新版本。例如，v1.0中有bug的客户端必须升级到v1.0.5。如果错误发生在其他版本中，我们将在那里修复它
• 如果客户需要新功能，我们将以最新版本进行开发，如果客户需要，我们将强制他们升级。例如，v1.0.5中需要新版本的客户端必须升级到v1.2
• 如果给定版本的所有客户端都升级，我们将删除该版本分支。例如，当v1.0的客户端升级时，我们将取消v1.0发布分支

因此，我的问题按重要性排序如下：

我的方法有效吗？你看到什么问题了吗

git流对于这种“多版本场景”有什么模式吗

Gitflow有一个主分支。没有主分支行可以吗？我们可以把不同的发行分支视为“大师”吗？

您将如何命名Dev和release分支

你的方法应该有效。GitFlow没有什么神奇之处，满足您需求的变体也不错。Git本身对于不同的工作流没有问题。Github流就是一个很好的例子，请看

您可以考虑以下几点：

a） “最小惊喜原则”：尽可能接近标准。这意味着您i）将开发人员指向web上可用的文档，而不是编写所有内容ii）使新开发人员更容易进入或仅处理您的项目。 因此，您应该保留主分支，不是因为它是需要的，而是因为它可能会在不存在时混淆人们，并且您必须在未来几年中解释这一点。 git中的分支是“只是”名称（好吧，更多一点，但你明白我的意思），所以将它们命名为相同名称的唯一原因是惯例，这使人们更容易理解

b） 有多少开发人员正在从事这些项目？如果有很多，可以考虑DEV分支是一个集成分支，并使用主分支作为稳定分支。拥有一个允许不稳定的开发分支可能会解决许多开发人员的许多问题。两个团队提交，一个来自功能，一个来自热修复，构建变红，团队互相指责，第三个团队试图获得新的发布分支，但无法。拥有一个稳定的、始终是绿色的构建主分支，您甚至可以通过拉请求来保护它，这是非常好的，并且有助于创建一个更轻松的环境

2） 基本的Gitflow是以发布为中心的，所以不完全是这样。您同时拥有多个版本。所以你就快到了，但是标准的工具，比如[Jakob Ehn的]（）-非常棒-会让你在打开一个新版本之前尝试关闭一个版本。让雅各布放松一下，这个工具会对你有用的。否则，只需遵循约定，但手动操作即可——这也很有效

3） 见上文第1点，关于大师以及为什么不拥有它可能不是一个好主意。当然，你可以把发布分支看作是一种大师，但在你的描述中，它们并不是这样。如果是这样的话，哪一个是真正的主控对象，您从中创建特征分支的对象，以及您认为最新的对象？有一个稳定的主人可以解决很多突然出现的问题

4） Dev或Develop，那么特性的名称应该尽可能接近它的功能，比如Dev/NewHelpPage或feature/NewHelpPage（更接近gitflow约定）。发布分支，看起来您已经遵循了语义版本控制（）原则，所以为什么不使用它：Release/V1.0、Release/V1.1等等。然后将发布一个修补程序分支/V1.0.1。
命名方式应便于开发人员理解，最好不必询问周围的任何人

保持它的简单，尽可能地遵循惯例，它往往会奏效。Git本身主要适用于任何分支方案

[编辑]

---

刚和Jakob聊了一会儿，他说他有支持分支机构的请求，这可能是你真正想要的。他还指出，在不同的gitflow场景中，底部是支持分支的流

谢谢你的回答：-）