针对项目的多个发布版本的Gitflow策略

Question

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

计划是：

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

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

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

方法是：

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

所以我的重要性问题是：

1. 我的方法会起作用吗？你能看到的任何问题吗？
2. git-flow是否有针对此＆＃34;多个版本场景＆＃34;？
的任何模式
3. Gitflow有一个Master分支。没有Master分支可以吗？我们可以将不同的Release分支视为＆＃34; Master＆＃34;？
4. 您如何命名Dev和Releases分支？

Answer 1

1. 你的方法应该有效。 GitFlow没有什么神奇之处，满足您需求的变化也很好。 Git本身对不同的工作流程没有任何问题。一个很好的例子是Github流程，看看http://scottchacon.com/2011/08/31/github-flow.html。

您可以考虑的一些事项：

a）“最少惊喜的原则”：尽量保持尽可能接近标准。这意味着你i）将开发人员指向网络上的可用文档，而不是编写所有内容.ii）使新开发人员更容易进入或只是使用您的项目。 因此，你应该保留主分支，而不是因为它是必需的 - 它不是，但是因为当它不存在时它可能会让人感到困惑，你将不得不在未来几年解释它。 git中的分支是“正义”名称（好吧，多一点，但你得到了我的意思），所以将它们命名为相同的唯一理由就是惯例 - 让人们容易理解。

b）有多少开发人员正在进行这些项目？如果有很多，您可以将Dev分支视为集成分支，并使用master分支作为稳定分支。拥有一个允许不稳定的开发分支可能会解决许多开发人员的许多问题。两个团队提交，一个来自功能，一个来自修补程序，构建变为红色，团队互相指责，第三个团队试图推出新的发布分支，但不能。拥有一个稳定的，始终是绿色的构建主分支，你甚至可以通过拉取请求来保护它是非常好的，并且使环境更加轻松。

2）基本Gitflow以发布为中心，所以并不完全。您同时拥有多个版本。所以你几乎就在那里，但标准工具，如[Jakob Ehn]（https://github.com/jakobehn）Gitflow extention to Visual Studio - 这是超级大的 - 会让你尝试在允许打开一个新版本之前关闭一个版本。请雅各布放松一下，该工具将为您服务。否则，只需按照约定，但手动执行 - 这也有效。

3）请参阅上面关于主人的第1点以及为什么不拥有它可能不是一个好主意。但是当然你可以认为发布分支是一种主人，但它们在你的描述中并没有真正表现出来。如果是这样，哪一个是真正的主人，你创建的那个功能从哪个分支，你认为最新的？拥有一个稳定的大师解决了很多没有弹出的问题。

4）开发或开发，然后功能应该具有尽可能接近的功能名称，如Dev / NewHelpPage或Feature / NewHelpPage（更接近gitflow约定）。发布分支，看起来您已经遵循语义版本控制（http://semver.org）原则，所以为什么不使用它：Release / V1.0，Release / V1.1等等。然后，修补程序分支是Release / V1.0.1 让命名是让开发者很容易理解它是什么，最好不需要问周围的人。

保持简单，尽可能遵循惯例，并且它往往会成功。 Git本身适用于任何分支方案。

[编辑] 刚与Jakob进行了快速聊天，他说他有支持分支机构的请求，这可能就是你真正追求的。他还在不同的gitflow场景中指出this excellent post，在底部有支持分支的流程。