我们使用 JIRA 作为我们的票务系统。新的错误/票证被提交到该系统。修复错误后，我们会创建一个新版本并在我们的开发服务器上对其进行测试。如果一切正常，我们会将其推送到实时服务器。现在我通常在主干上工作，没有任何分支来修复错误。这当然是个问题。因为我们的系统中可能存在许多错误，但一次只能修复某些错误。但是，如果我将它们全部固定在主干而不是分支中，那么即使我们没有足够的时间来测试它们，我们也将被迫全部测试它们。您通常如何修复错误和分支等？（我不确定我是否解释得很好）。
问问题
3660 次
8 回答
8
这是我使用的策略。我在主干开发。软件发布后，我将其分支（例如 v1.0）。当错误出现时，修复分支主干，然后合并回主干。这是可用策略的一个很好的概要：http ://www.cmcrossroads.com/bradapp/acme/branching/branch-structs.html
于 2010-01-29T15:57:06.040 回答
3
我不确定这是否是正常策略，但我们在主干上完成所有工作，然后将错误修复反向移植到发布分支中。我们的主干始终是“不稳定的”，当我们觉得我们的主干处于可发布状态时，我们会将其分支到发布分支。从那时起，buyfixes 被移植回发布分支，新功能只会添加到主干。这意味着您可以通过测试运行您的发布分支并专注于测试错误修复。
于 2010-01-29T15:58:54.323 回答
2
一种常见的操作模式是部署的软件存在于一个单独的分支中，该分支只接收错误修复。您实际开发这些修复程序的位置几乎无关紧要。为了避免干扰当前的开发，在“实时”分支上开发修复程序是有意义的，然后测试/提交/部署到实时系统，然后将修复程序合并回主干。
于 2010-01-29T16:03:29.467 回答
2
我们有同样的问题（或几乎），我认为每个开发团队都有。不幸的是，我还不能通过经验给你答案，而只能是理论上的答案。
在我看来，只要是bug修复，就应该尽快部署。我要实现的是一个特性分支策略，一个发布分支。这意味着我们必须区分功能和错误。并且部署的内容是单独分支的（在我们的例子中是标记的）
这样做，您仍然可以在主干上处理错误，并将它们部署到您的测试服务器，一旦它经过测试和批准，就可以将其分支到发布分支并进行部署。您还可以将错误修复合并到您的功能分支中，或者稍后在您计划将其部署到测试服务器时尝试合并该功能。
无论如何，我认为最重要的是将阻止您部署较小错误修复的长期工作进行分支。 如果分支太多，就会出现合并问题。如果您没有足够的分支，您将遇到部署灵活性问题。
于 2010-01-29T16:10:50.217 回答
1
我不建议对每个报告的错误进行分支。正如您所说，您可能不会决定修复报告的每个错误，这意味着您将在某个时候修剪很多死枝。
如果您的工具和语言支持它，那么在您决定修复的每个错误（以及您决定实施的功能）上进行分支并不是一个坏主意。它允许您在有预算和计划时开发和测试每个错误修复/功能，并在您准备好时将它们合并回主干。
于 2010-01-29T15:59:41.177 回答
1
这取决于您的版本控制系统。如果您使用 git，其中分支便宜且合并容易，那么我肯定会为每个修复创建一个新分支。这使您可以保持彼此独立的错误修复，从而在合并到主干/主干的内容以及何时合并方面具有更大的灵活性。
另一方面，如果您使用的是 Subversion，分支会更加昂贵（在创建和切换/更新方面）并且合并更加困难。通常，新分支的成本/收益比不够高（尤其是对于小错误），因此值得。
于 2010-01-29T16:17:43.070 回答
0
我们将分支拆分为产品版本/发布，以便每个发布都有自己的分支。分支的发布已经过测试，因此我们只需要测试应用于该分支的修复即可。
此外，每个产品版本都有一个 dev 和一个 main 分支。开发人员可以自由地提交到 dev 分支，而不必担心干扰发布（仅限其他开发人员！）
于 2010-01-29T16:10:20.450 回答
0
除非您使用的是分布式 SCM（Mercurial、Git 等），其中分支基本上是免费的，否则对每个 bug 进行分支听起来都是不合理的工作量。
使用中央存储库 SCM 的通常策略是记录应该修复错误的修订版，并针对使用更高版本的构建进行测试。然后，您可以将相关修订合并回发布分支。
我们正在使用 mercurial，在分布式 SCM 中分支修复错误然后合并更改是非常可行的
于 2010-01-29T16:17:25.007 回答