3

对于糟糕的问题标题，我感到非常抱歉，但我会尝试更详细地解释一下自己：

我正在为我的软件项目使用 Git（但我猜在这种情况下特定软件并不重要）。与许多项目一样，我计划发布各种版本。当有发布时，我可能会为提交分配一个标签——例如“1.0”。时间流逝，代码被黑，最终发布了一个带有另一个标签的版本——这次是“2.0”。

有一天，我注意到一个严重的错误，它存在于 1.0 和 2.0 版本中，需要修复。为了让事情变得困难（也可能更现实），我不能只在当前的主干/主干中修复它并假设每个人都会使用它，因为 2.0 与 1.0 存在一些向后不兼容，人们很懒惰并且不要不想升级。

那么，为了支持这种行为，有什么好的方案：能够在旧版本中进行更改。git describe由于命令（“ [latest tag]-[commits since the tag]-[current commit hash]”）的输出，Git 似乎在某种程度上将标签等同于发布。那么，我可能无法避免完全使用标签。

我觉得标签和分支的组合是个好主意，但由于某种原因，我无法用这个来解决细节问题。

4

3 回答 3

1

您需要一个分支 - 您将在从发布标记开始的分支上进行维护修复和发布，同时在主（主）分支上继续进行持续开发。

于 2009-01-18T23:10:56.787 回答
1

当您提到分支和标签时，您似乎已经有了大部分答案。一个标签用于标记某个偶数（如发布），分支用于并行开发。某个版本的维护通常在分支上完成，您可以使用大多数当前 VCS 挑选变更集，以将给定的错误修复从 head/trunk 导入分支，反之亦然。

您可以处理 head/trunk/master（无论您“当前”开发分支的名称是什么），并在您的各种维护分支中合并错误修复。一旦您完成了主要或次要版本，您就可以创建一个用于维护的分支。

有很多方法可以实现您想要的。

于 2009-01-18T23:41:47.910 回答
1

您肯定想考虑为此使用分支。Git 很好地支持这种类型的开发分支。

例如，您的线性版本历史可能如下所示：

---A---B---C[1.0]---D---E---F[2.0]---G---H

如果你在 1.0 中发现了一个 bug 并想要修复它，你不能简单地在提交 C 和 D 之间插入一个新的提交。所以，你可以像这样创建一个分支：

---A---B---C[1.0]---D---E---F[2.0]---G---H[2.1]
            \
             C1---C2[1.1]

提交 C1 和 C2 修复了该分支中的问题，您可以在其中标记版本 1.1。现在假设您在 2.1 版中进行了更改 (G)，您希望将其向后移植到 1.1 版以在那里进行相同的更改。您可以使用git cherry-pick执行以下操作：

---A---B---C[1.0]---D---E---F[2.0]---G---H[2.1]
            \
             C1---C2[1.1]---G1[1.2]

提交 G1 与提交 G 相关，但它可以应用在 1.1 版而不是 2.0 版之上。

在这些示例中，分支（额外的开发流）是关键概念，而标签只是一种方便的方式来命名项目在特定时间点所处的状态。Git 支持许多其他操作分支的方法，尤其是使用强大的git rebase命令。

于 2009-01-19T00:31:03.363 回答