一个项目的多个版本的Gitflow策略

Question

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

计划是：

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

我们将努力迫使老客户升级到最新版本，但由于项目和市场的性质，可能需要几个月(几年？)让客户升级。

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

​

办法是：

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

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

1. 我的方法有用吗？你看到什么问题了吗？
2. 对于这种“多版本方案”，git-flow有什么模式吗？
3. Gitflow有一个主分支。没有师父的分支可以吗？我们能把不同的发行分支看作是“大师”吗？
4. 您将如何命名开发和发布分支？

Answer 1

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

有几件事你可以考虑：

( a)“最不惊讶的原则”：尽量接近标准。这意味着你(我)把开发者指向网络上可用的文档，而不是写下所有的东西)，使新的开发人员更容易进入你的项目或仅仅与你的项目一起工作。因此，你应该保留主分支，不是因为它是需要的，而是因为它可能会在它不在的时候迷惑人们，而且你将不得不在未来的几年里解释这一点。git中的分支是“只是”名称(嗯，稍微多一点，但您理解我的意思)，所以将它们命名相同的唯一原因是惯例--使人们更容易使用。

( b)有多少开发人员在执行这些项目？如果有很多，您可以将Dev分支看作一个集成分支，并使用主分支作为稳定分支。拥有允许不稳定的开发分支可能会解决许多devs的问题。两个团队承诺，一个来自特性，一个来自一个修复程序，构建变红了，团队互相指责，第三个团队试图获得一个新的发布分支，但不能。拥有一个稳定的，总是绿色的主分支，你甚至可以通过拉请求来保护它，这是非常好的，并为一个更轻松的环境。

2)基本的Gitflow以发行版为中心，所以并不完全是这样。同时有多个版本。因此，您已经接近尾声了，但是标准工具，比如雅各布·伊恩氏病 Gitflow扩展到Visual --这是非常棒的--将使您在允许打开新版本之前尝试关闭一个发行版。让雅各布放松一下，这个工具会对你有用的。否则，只需按照惯例行事，但要手动执行--这也有效。

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

4)开发或开发，那么特性的名称应该尽可能接近它所做的事情，比如Dev/NewHelpPage或Feature/NewHelpPage (以更接近gitflow约定)。发布分支，看起来您已经遵循了语义版本控制(http://semver.org)原则，那么为什么不使用它: Release/V1.0、Release/V1.1等等。然后发布一个修补程序分支/v1.0.1。

让命名更容易理解它是什么，最好不必问周围的任何人。

保持简单，尽你所能遵循惯例，这样就能解决问题。Git本身主要适用于任何分支方案。

编辑刚刚和Jakob聊了一会，他说他有支持分支的请求，这可能就是你真正想要的。他还指出了这个极佳的职位在不同的gitflow场景中，在底部有支持分支的流。