2

我的工作正在从 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.2、v1.3 和 master 分支中修复它并更新客户端 B 和 C。我们不会为这些更改创建新分支，但从技术上讲，它们会是版本 v1.2.1 和 v1.3.1。

当 v1.3 已经推出时，当我们需要能够创建 v1.2.1 时，我们看不到如何切换到仅使用标签进行发布。

谁能推荐一个比每个版本创建一个分支并在其中进行开发更适合我们的模型master？

4

3 回答 3

1

您可以根据旧标签创建新分支。如果您在继续前进时发现 v1.2 中的严重错误，只需从 v1.2 标记创建一个新分支，在那里修复错误，将其标记为 1.2.1，然后将修复选择到所有其他标记中（现在是分支）您正在维护的。

即使您没有在 中进行稳定版本master，这仍然适用。

于 2012-05-08T03:22:08.410 回答
0

您可以使用稳定的 master 并且仍然执行每个版本的分支（事实上，我建议您这样做）。

如果您需要为较早的主要版本修补次要版本，您将希望为每个主要版本都有一个分支，并且您不应该试图避免这种情况。

但是，这并不能阻止您将 master 声明为一个稳定的分支并让人们使用单独的分支进行开发，只有在他们确定它们是稳定的时才将这些分支合并到 master 中。

保持 master 稳定有很多好处：

  • 这意味着任何创建新功能分支的人都有其分支的已知良好基础。
  • 它使发布变得非常容易——您只需从 master 分支并使其成为您的发布。

您仍然可以使用标签来标记给定主要版本的初始分支点（以及主要分支的任何次要版本版本）。

于 2012-05-08T03:22:27.177 回答
0

我们喜欢这种开发方法，但它似乎不允许将修补程序应用于已发布的版本。

你看到名为 的分支了hotfixes吗？从需要修补程序时开始分支master，其更改返回到master, 以及develop?

今天我们使用分支管理我们的发布，master 用于开发。

nvie.com 分支模型不master用于开发，它使用develop. master应始终是该产品的最新发布版本。

如果在 v1.2 中发现了严重错误，我们会在 v1.2、v1.3 和 master 分支中修复它并更新客户端 B 和 C。我们不会为这些更改创建新分支，但从技术上讲，它们会是版本 v1.2.1 和 v1.3.1。

找出master该错误发生的最早版本；从该标签创建一个hotfix分支，然后将修复反向移植到develop. 实际上，您应该从 bug 中出现的hotfix每个版本化标记创建一个分支master，并将其向后移植到那些，然后最后回到master它的头部。

于 2012-05-08T03:23:34.603 回答