我的工作正在从SVN切换到Git的过程中，我们正在重新评估如何使用分支和标签。
我们已经看到了使用 master 作为始终稳定版本的模型，其中标签用于识别版本，单独的开发分支用于不稳定代码 (http://nvie.com/posts/a-successful-git-branching-model/(。
我们喜欢这种开发方法，但它似乎不允许将修补程序应用于已发布的版本。
我们的产品安装了多个客户端服务器，每个服务器可能安装了不同的版本(出于我们无法控制的各种原因(。 今天，我们使用分支管理我们的版本，master用于开发。
例如，我们可能有 3 个不同版本的客户端：
- 客户端 A - v1.1
- 客户端 B - v1.2
- 客户端 C - v1.3
发现严重错误，我们会在 v1.2、v1.3 和主分支中修复它，并更新客户端 B 和 C。 我们不会为这些更改创建新分支，但从技术上讲，它们将是版本 v1.2.1 和 v1.3.1。
当我们需要在 v1.2.1 已经推出时能够创建 v1.2.1 时，我们看不到如何切换到仅使用版本的标签。
任何人都可以推荐一个比为每个版本创建一个分支并在master中进行开发更适合我们的模型吗？
您可以基于旧标记创建新分支。如果您在继续操作时在 v1.2 中发现严重错误，只需从 v1.2 标签创建一个新分支，修复该错误，将其标记为 1.2.1，然后将修复程序挑选到您正在维护的所有其他标签(现在是分支(中。
即使您没有在master中发布稳定版本，这仍然适用。
您可以使用稳定的主节点，并且仍然可以按版本进行分支(事实上，这就是我建议您做的(。
如果您需要修补早期主要版本的次要版本，则需要为每个主要版本设置一个分支，并且不应试图避免这种情况。
但是，这并不能阻止您声明 master 是一个稳定的分支，并让人们使用单独的分支进行开发，只有在他们确定这些分支是稳定的时才将这些分支合并到 master 中。
保持主站稳定有许多好处：
- 这意味着任何创建新功能分支的人都有其分支的已知良好的基础。
- 它使发布变得非常容易 - 您只需分支出 master 并将其作为您的发布。
您仍然可以使用标记来标记给定主要版本(以及主要分支之外的任何次要版本(的初始分支点。
我们喜欢这种开发方法，但它似乎不允许将修补程序应用于已发布的版本。
你看到名为hotfixes的分支了吗？当需要修补程序时，它会从master分支，其更改会回到master，以及develop？
今天，我们使用分支管理我们的版本，而 master 用于开发。
nvie.com 分支模型不使用master进行开发，而是使用develop。 master应始终是产品的最新版本。
如果在 v1.2 中发现严重错误，我们会在 v1.2、v1.3 和主分支中修复它，并更新客户端 B 和 C。我们不会为这些更改创建新分支，但从技术上讲，它们将是版本 v1.2.1 和 v1.3.1。
找出发生错误的master的最早版本;从该标记创建一个hotfix分支，然后将修复程序向后移植到 develop 。实际上，您应该在错误发生master的每个版本化标记创建一个hotfix分支，并将其向后移植到这些分支，然后最终回到其头部的master。