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