一个项目的多个发布版本的 Gitflow 策略
Gitflow strategy for multiple released versions of a project
我正在为我的项目设计分支和合并策略（我们使用 TFS）。项目计划有多个发布版本。目前我们正在测试 v1.0alpha 并在 v2.0
中工作
计划是：
- 测试人员即将批准后，版本 v1.0 将发布给一个客户。
- 版本 v1.1（已在开发中）将部署到 5-6 个客户端
- 版本 v1.2 将安装到数十个客户端。
- 等等
我们将尝试强制将旧客户端升级到最新版本，但由于项目和市场的性质，客户端升级可能需要数月（数年？）。
我们想使用标准 gitflow，但似乎更适合使用单一版本。我设计了一个简化的 git 流程：
方法是：
- 如果客户想要修复错误，我们将在他的版本的 Release 分支中修复它，他必须升级到他的版本的最新版本。例如，v1.0 中存在错误的客户端必须升级到 v1.0.5。如果错误发生在其他版本中，我们将在那里修复它。
- 如果客户想要新功能，我们将在最新版本中开发它，并在他们需要时强制他们升级。例如 v1.0.5 中想要新版本的客户端必须升级到 v1.2
- 如果给定版本的所有客户端升级，我们将删除该版本分支。例如v1.0的客户端升级时我们会烧掉v1.0 Release分支。
所以我的问题按重要性排序是：
- 我的方法行得通吗？您能看到任何问题吗？
- git-flow 是否有此 "multiple versions scenario" 的任何模式？
- Gitflow 有一个 Master 分支。没有 Master 分支可以吗？我们可以将不同的 Release 分支视为 "Master"?
- 您将如何命名 Dev 和 Releases 分支？
- 您的方法应该有效。 GitFlow 没有什么神奇之处，可以满足您的需求。 Git 本身对不同的工作流程没有问题。一个很好的例子是 Github 流，看看 http://scottchacon.com/2011/08/31/github-flow.html .
您可以考虑的一些事项：
a) "Principle of least surprise"：尽量保持接近标准。这意味着您 i) 将开发人员指向网络上可用的文档，而不是将所有内容都写下来 ii) 让新开发人员更容易进入或只是使用您的项目。
因此，你应该保留 master 分支，不是因为它是必需的——它不是，而是因为当它不存在时它可能会让人们感到困惑，而且你将不得不在未来几年解释这一点。
git 中的分支是 "just" 个名称（好吧，有点多，但你明白我的意思），所以将它们命名为相同的唯一原因是约定 - 方便人们使用。
b) 有多少开发人员在从事这些项目？如果有很多，可以考虑将Dev分支作为集成分支，将master分支作为稳定分支。拥有一个允许不稳定的开发分支可能会解决许多开发人员的许多问题。两个团队提交，一个来自功能，一个来自修补程序，构建变红，团队互相指责，第三个团队试图推出一个新的发布分支，但不能。拥有一个稳定的、始终绿色的构建主分支，您甚至可以通过拉取请求来保护它，这非常好，并且可以营造更轻松的环境。
2) 基本 Git 流程以发布为中心，所以不完全是。您同时拥有多个版本。所以你快到了，但是标准工具，比如 [Jakob Ehn 的] (https://github.com/jakobehn) Gitflow extention to Visual Studio - 非常棒 - 会让你在允许打开新版本之前尝试关闭版本。让 Jakob 放松一下，并且该工具将为您工作。否则，只需遵循惯例，但手动执行 - 这也有效。
3) 请参阅上面关于 master 的第 1 点以及为什么没有它可能不是一个好主意。但是当然，您可以将发布分支视为某种大师，但在您的描述中它们并不是那样的。如果是这样，哪个才是真正的大师，您从中创建功能分支的那个，以及您认为是最新的那个？有一个稳定的主人可以解决很多没有的问题。
4) Dev 或 Develop，那么 features 的名称应该尽可能接近它的功能，例如 Dev/NewHelpPage，或 Feature/NewHelpPage（更接近 git流约定）。发布分支，看起来你已经遵循语义版本控制（http://semver.org）原则，那么为什么不使用它：Release/V1.0，Release/V1.1 等等。修补程序分支然后是 Release/V1.0.1 .
命名应该让开发人员很容易理解它是什么，最好不需要问周围的任何人。
保持简单，尽可能遵循惯例，它往往会奏效。 Git 本身几乎适用于任何分支方案。
[编辑]
刚刚与 Jakob 进行了快速交谈，他说他有支持支持分支机构的请求，这可能是您真正想要的。他还指出 this excellent post 不同的 git 流程场景，底部是支持分支的流程。
我正在为我的项目设计分支和合并策略（我们使用 TFS）。项目计划有多个发布版本。目前我们正在测试 v1.0alpha 并在 v2.0
中工作计划是：
- 测试人员即将批准后，版本 v1.0 将发布给一个客户。
- 版本 v1.1（已在开发中）将部署到 5-6 个客户端
- 版本 v1.2 将安装到数十个客户端。
- 等等
我们将尝试强制将旧客户端升级到最新版本，但由于项目和市场的性质，客户端升级可能需要数月（数年？）。
我们想使用标准 gitflow，但似乎更适合使用单一版本。我设计了一个简化的 git 流程：
方法是：
- 如果客户想要修复错误，我们将在他的版本的 Release 分支中修复它，他必须升级到他的版本的最新版本。例如，v1.0 中存在错误的客户端必须升级到 v1.0.5。如果错误发生在其他版本中，我们将在那里修复它。
- 如果客户想要新功能，我们将在最新版本中开发它，并在他们需要时强制他们升级。例如 v1.0.5 中想要新版本的客户端必须升级到 v1.2
- 如果给定版本的所有客户端升级，我们将删除该版本分支。例如v1.0的客户端升级时我们会烧掉v1.0 Release分支。
所以我的问题按重要性排序是：
- 我的方法行得通吗？您能看到任何问题吗？
- git-flow 是否有此 "multiple versions scenario" 的任何模式？
- Gitflow 有一个 Master 分支。没有 Master 分支可以吗？我们可以将不同的 Release 分支视为 "Master"?
- 您将如何命名 Dev 和 Releases 分支？
- 您的方法应该有效。 GitFlow 没有什么神奇之处，可以满足您的需求。 Git 本身对不同的工作流程没有问题。一个很好的例子是 Github 流，看看 http://scottchacon.com/2011/08/31/github-flow.html .
您可以考虑的一些事项：
a) "Principle of least surprise"：尽量保持接近标准。这意味着您 i) 将开发人员指向网络上可用的文档，而不是将所有内容都写下来 ii) 让新开发人员更容易进入或只是使用您的项目。 因此，你应该保留 master 分支，不是因为它是必需的——它不是，而是因为当它不存在时它可能会让人们感到困惑，而且你将不得不在未来几年解释这一点。 git 中的分支是 "just" 个名称（好吧，有点多，但你明白我的意思），所以将它们命名为相同的唯一原因是约定 - 方便人们使用。
b) 有多少开发人员在从事这些项目？如果有很多，可以考虑将Dev分支作为集成分支，将master分支作为稳定分支。拥有一个允许不稳定的开发分支可能会解决许多开发人员的许多问题。两个团队提交，一个来自功能，一个来自修补程序，构建变红，团队互相指责，第三个团队试图推出一个新的发布分支，但不能。拥有一个稳定的、始终绿色的构建主分支，您甚至可以通过拉取请求来保护它，这非常好，并且可以营造更轻松的环境。
2) 基本 Git 流程以发布为中心，所以不完全是。您同时拥有多个版本。所以你快到了，但是标准工具，比如 [Jakob Ehn 的] (https://github.com/jakobehn) Gitflow extention to Visual Studio - 非常棒 - 会让你在允许打开新版本之前尝试关闭版本。让 Jakob 放松一下，并且该工具将为您工作。否则，只需遵循惯例，但手动执行 - 这也有效。
3) 请参阅上面关于 master 的第 1 点以及为什么没有它可能不是一个好主意。但是当然，您可以将发布分支视为某种大师，但在您的描述中它们并不是那样的。如果是这样，哪个才是真正的大师，您从中创建功能分支的那个，以及您认为是最新的那个？有一个稳定的主人可以解决很多没有的问题。
4) Dev 或 Develop，那么 features 的名称应该尽可能接近它的功能，例如 Dev/NewHelpPage，或 Feature/NewHelpPage（更接近 git流约定）。发布分支，看起来你已经遵循语义版本控制（http://semver.org）原则，那么为什么不使用它：Release/V1.0，Release/V1.1 等等。修补程序分支然后是 Release/V1.0.1 .
命名应该让开发人员很容易理解它是什么，最好不需要问周围的任何人。
保持简单，尽可能遵循惯例，它往往会奏效。 Git 本身几乎适用于任何分支方案。
[编辑] 刚刚与 Jakob 进行了快速交谈，他说他有支持支持分支机构的请求，这可能是您真正想要的。他还指出 this excellent post 不同的 git 流程场景，底部是支持分支的流程。