我应该为报告的每个新错误创建一个新分支吗？
我们使用 JIRA 作为我们的票务系统。新的错误/票据被提交到该系统。一旦修复了错误，我们就会创建一个新的版本并在我们的开发服务器上测试它。如果一切顺利，我们会将其推送到实时服务器。现在我通常在主干上工作，没有任何分支来修复错误。这当然是个问题。因为我们的系统中可能存在很多错误，但一次只能修复某些错误。然而，如果我将它们全部修复在主干而不是分支中，那么我们就被迫对它们进行全部测试，即使我们没有足够的时间来测试它们。你通常如何修复错误和分支等？ （我不确定我是否解释得很好）。
We use a JIRA as our ticket system. New bugs/tickets are submitted to that system. Once a bug is fixed, we create a new build and test it on our dev server. If everything is good we push it to the live server. Now I usually work on the trunk without any branching to fix the bugs. This is of course a problem. Because there can be many bugs in our system, but only certain ones get fixed at a time. However if I fix all of them in the trunk instead of a branch, then we are forced to test them all even if we did not had enough time to test them all. How do you usually fix bugs and branch etc..? (I am not sure if I explained it very well).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
这取决于您的版本控制系统。如果您使用 git，其中分支很便宜并且合并很容易，那么我肯定会为每个修复创建一个新分支。这允许您使错误修复彼此独立，从而在合并到主干/主干的内容以及何时合并方面提供更大的灵活性。
另一方面，如果您使用 Subversion，分支会更昂贵（在创建和切换/更新方面）并且合并会更困难。通常，新分支的成本/效益比不够高（特别是对于小错误），因此不值得。
It depends on your version control system. If you're using git, where branches are cheap and merges are easy, then I would definitely create a new branch for each fix. This allows you to keep bug fixes independent of each other, allowing greater flexibility with respect to what gets merged into the master/trunk, and when.
On the other hand, if you're using Subversion, branches are more expensive (in terms of creating and switching/updating) and merging is more difficult. Often the cost/benefit ratio of a new branch isn't high enough (especially for small bugs) to make it worthwhile.
一种常见的操作模式是已部署的软件位于仅接收错误修复的单独分支中。您实际在哪里开发这些修复程序基本上是无关紧要的；为了避免干扰当前的开发，在“实时”分支之上开发修复程序是有意义的，然后测试/提交/部署到实时系统，然后将修复程序合并回主干。
One common mode of operations is that the deployed software lives in a separate branch which receives only bugfixes. Where you actually develop those fixes is mostly irrelevant; to avoid interference with the current development, it makes sense to develop the fix on top of the "live" branch, then test/commit/deploy to the live system and aftewards merge the fix back into the trunk.
我们有同样的问题（或几乎），我认为每个开发团队都有这个问题。不幸的是，我还不能通过经验给你答案，而只能给你一个理论上的答案。
在我看来，只要是bug修复，就应该尽快部署。
我要实现的是功能分支策略和发布分支。
这意味着我们必须区分功能和错误。并且部署的内容是单独分支的（在我们的例子中是标记的）
这样做，您仍然可以在主干上处理错误，并将它们部署到您的测试服务器，一旦经过测试和批准，就可以将其分支到发布分支，部署它。
您还可以将错误修复合并到功能分支中，或者稍后当您计划将其部署到测试服务器时尝试合并该功能。
无论如何，我认为最重要的是对长期工作进行分支，以防止部署较小的错误修复。
如果分支太多，就会遇到合并问题。如果分支不够，就会遇到部署灵活性问题。
We have the same problem (or almost), and I think every developer team has it. I can unfortunately not yet give you an answer by experience, but only a theoretical one.
In my opinion, as long as it's a bug fix, it should be deployed as soon as possible.
What I am about to implement is a feature branch strategy, and a release branch.
This means we have to differentiate features from bugs. and what is deployed is branched separately (or labeled, in our case)
Doing this, you can still work on the trunk for the bugs, and deploy them to your testing server, and once it's tested and approved branch it to the release branch and deploy it.
you can also merge-in the bug fixes into your feature branch, or try to merge the feature later when you plan to deploy it to the testing server.
Anyway, the most important I think is to branch the long work that prevent you from deploying smaller bug fixes.
If you branch too much, you will have a merging problem. If you don't branch enough, you will have a deployment flexibility issue.
我不建议对每个报告的错误进行分支。正如您所说，您可能不会决定修复报告的每个错误，这意味着您在某个时候会有很多死枝需要修剪。
如果您的工具&语言支持它，在您决定修复的每个错误（以及您决定实现的功能）上进行分支并不是一个坏主意。当您有预算和时间表时，它允许您开发和测试每个错误修复/功能，并在准备好时将它们合并回主干。
I wouldn't recommend branching on every reported bug. As you said, you may not decide to fix every bug that's reported, which would mean that you'd have a lot of dead branches to prune at some point.
If your tools & language support it, branching on every bug you decide to fix (and feature you decide to implement) isn't a bad idea. It allows you to develop and test each bugfix/feature when you have the budget and schedule to do so, and merge them back into trunk when you are ready.
我们将分支分为产品版本/发行版，以便每个发行版都有自己的分支。该分支的发布已经过测试，因此我们只需要测试应用于该分支的修复即可。
此外，每个产品版本都有一个开发分支和一个主分支。开发人员可以自由地提交到 dev 分支，而不必担心干扰发布（仅限其他开发人员！）
We split our branches into product versions / release, so that each release has its own branch. The release from the branch is tested, and so we only need to test the fixes applied to that branch.
Additionally each product version has a dev and a main branch. Developers are allowed to freely commit to the dev branch without fear of interfering with the Release (only other developers!)
除非您使用的是分布式 SCM（Mercurial、Git，...），其中分支基本上是免费的，否则对每个错误进行分支听起来像是一项不合理的工作量。
中央存储库 SCM 的常用策略是记录应该修复错误的修订版，并针对使用较新修订版制作的构建进行测试。然后，您可以将相关修订合并回发布分支。
我们使用 Mercurial，通过分支来修复错误，然后将更改合并回去，这在分布式 SCM 中是完全可行的
Unless you're using a distributed SCM (Mercurial, Git, ...) where branching is basically free, branching on every bug sounds like an unreasonnable amount of work.
The usual strategy with central repository SCM is to note the revision that is supposed to fix the bug, and test against a build made with a later revision. You can then merge the concerned revision back into the release branch.
We are using mercurial, and branching to fix bugs and then merge changes back is quite doable in a distributed SCM
这是我使用的策略。我在主干上开发。当软件发布时，我对其进行分支（例如 v1.0）。当错误出现时，修复分支主干，然后合并回主干。以下是可用策略的详细摘要：http://www.cmcrossroads.com/branching/branch-structs.html。 cmcrossroads.com/bradapp/acme/branching/branch-structs.html
Here is the strategy I use. I develop in the main trunk. When the software is released, I branch it (say v1.0). When bugs come in, fix in the branch trunk and then merge back to main trunk. Here is a good synopsis of strategies that are available: http://www.cmcrossroads.com/bradapp/acme/branching/branch-structs.html
我不确定这是否是正常策略，但我们在主干上完成所有工作，然后将错误修复向后移植到发布分支中。我们的主干总是“不稳定”，当我们觉得主干处于可发布状态时，我们将其分支到发布分支。从那时起，购买修复程序将被移植回发布分支，并且新功能只会添加到主干中。这意味着您可以通过测试运行您的发布分支并专注于测试错误修复。
I'm not sure if it's the normal strategy but we do all work on the trunk and then backport bugfixes into release branches. Our main trunk is always 'unstable' and when we feel we have a trunk in a releasable state we branch it into a release branch. From then on buyfixes are ported back into the release branch and new functionality only gets added to the trunk. It means you can run your release branch through testing and focus on testing the bugfixes.