每一个小小的改变都需要分支吗？
我们有一个客户（谁有一个客户，谁有一个客户），他对代码库（PHP）的更改请求让我们发疯。 我们的第一个反应是只在 SVN 的主干中工作，但客户端经常回来并请求需要尽快将某些更改推送到实时服务器。 另一方面，其他更改的优先级突然降低，这些更改最初与其他更改分组（看起来）。
我们正在考虑为每个变更请求使用一个分支。这很疯狂吗？ 还有哪些其他解决方案可能有效？
谢谢！
编辑：这是一个很难选择正确答案的问题。 感谢大家的精彩回答。
编辑：我知道我选择的最佳答案并不是特别受欢迎。 我也想找到解决这个问题的技术方案。 但现在我认为，如果客户想要具有可以以模块化方式部署的功能的软件......这个问题不应该在我们使用版本控制系统时得到解决。 它必须被设计到软件中。
编辑：现在差不多一个月过去了，我的同事/客户说服了我，多个分支机构是正确的选择。 这不仅是由于客户的疯狂，而且还基于我们需要能够确定某个功能是否“准备好”或“需要更多工作”或其他什么。 我没有 SVN，但我们使用 SVN Cookbook 中的建议进行合并：将分支来自它分支到头修订版的修订版合并。
此外，使用这个系统，我们在某个时刻合并所有分支，这成为新的 QA，然后进行实时构建。 然后我们以此为基础进行分支。
最后一次编辑（可能）：几个月后，这个系统仍然在为我们工作。 我们为每张票创建分支，很少出现问题。 另一方面，我们确实尝试将人们正在做的事情分开......
两年后：我们现在使用 GIT，现在这个系统实际上是相当合理的。
We have a client (who has a client, who has a client) who is driving us mad with change requests to a code base (in PHP). Our first response was to just work in a main trunk in SVN, but the client often comes back and requests that a certain change needs to get pushed to the live servers ASAP. On the other hand, other changes get reduced in priority suddenly, which originally came grouped with other changes (seemingly).
We are thinking of using a branch for every change request. Is this mad? What other solutions might work?
Thanks!
Edit: This is a really hard question to choose the correct answer for. Thanks to everybody for your great answers.
Edit: I know that the best answer I chose was not particularly popular. I too wanted to find a technical solution to this problem. But now I think that if the client wants software with features that can be deployed in a modular fashion... this problem should not be solved in our use of the version control system. It would have to be designed into the software.
Edit: Now it's almost a month later and my coworker/client has convinced me that multiple branches is the way to go. This is not just due to the client's insanity, but also based on our need to be able to determine if a feature is "ready to go" or "needs more work" or whatever. I don't have the SVN with me, but we merge using the advice from the SVN Cookbook: you merge the branch from the revision it was branched to the head revision.
Also, using this system, we merge all branches at some point and that becomes the new QA and then live build. Then we branch from that.
Last Edit (Perhaps): Months later, this system is still working out for us. We create branches for every ticket and rarely have problems. On the other hand, we do try to keep things separate as far as what people are working on...
Two Years Later: We use GIT now, and now this system is actually quite reasonable.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（11）
也许 Subversion 并不是完成这项工作的最佳工具。 尽管在 SVN 中创建所有这些分支的成本很低，但重新合并它们可能会变得耗时且痛苦。
如果你看一下 GIT 而不是 SVN，你会发现版本控制系统通常在合并方面更强大。 除此之外，它还具有“樱桃采摘”的独特功能。 也就是说，可以轻松地从一个开发树“选取”单个提交并将其添加到另一棵开发树（实时分支）。 此外，在 GIT 中可以轻松方便地将多个提交合并为一个提交（您甚至可以从另一棵树添加到特定提交）。
因此，构建单一功能提交，然后挑选它们可能是适合您的解决方案。
Perhaps Subversion here is not the best tool for the job. Although creating all these branches is cheap in SVN, re-merging them can become time-consuming and painfull.
If you have a look at GIT instead of SVN, you will find a version control system which is more powerfull at merging in general. Added to that, it has the specific feature of "cherry picking". That is, single commits can be easily "picked" from one development tree and added to another (the live branch). Also, it is easy and convenient in GIT to merge several commits into one single one (you can even add to a specific commit from another tree).
So building up single-feature commits and then cherry-picking them could be the solution for you.
为您的客户的实时版本创建一个分支，为您的新开发创建一个分支，为您正在进行的更改创建一个分支怎么样？
当您没有被任务淹没时，可以在新的开发分支中工作。
当你修复那些让你抓狂的有趣东西时，就在正在进行的变更分支中工作。 当你得到修复后，将其合并到“live”分支和“newdevelopment”分支。
这样，您的客户的发行版就处于其自己的世界中，您的新开发将继续进行（并且可以在您需要时进行合并），并且您的维护也将被捕获。
我们在一个新的开发分支中工作，然后每次我们决定制作补丁时，我们都会对主干进行分支，然后将该补丁发送出去进行问答。 如果它来回一段时间，我们会在该分支中修复这些问题，并在必要时合并回主干，以确保一切同步。 如果在之前的版本中需要解决的问题很久之后又出现了，我们总是可以在该分支中修复它，然后再次将其合并到主干中。
What about creating a branch for your client's live version, a branch for your new development and a branch for your ongoing changes.
Work in the new development branch when you're not being inundated with tasks.
Work in the ongoing changes branch when you're fixing all that fun stuff they keep driving you crazy with. When you've got a fix, merge it to the "live" branch and to the "new development" branch.
That way your client's distribution is in its own world, your new development continues on (and can be merged whenever you need it) and your maintenance is also captured.
We work in a new development branch, then each time we decide to make a patch, we branch the trunk and then send that patch off for Q/A. If it goes back and forth a while, we work in that branch to fix those issues merging back to the trunk where necessary to ensure everything is in sync. If something came back long after the fact which needed to be addressed in a previous version, we can always fix it back in that branch, then again, just merge it into the trunk.
线程开启器解释的场景是功能分支模式的示例： http://svnbook.red-bean.com/en/1.5/svn.branchmerge.commonpatterns.html#svn.branchmerge.commonpatterns.feature
它们在以下情况下非常有用你必须保持主开发线（主干）的稳定，并且必须开发许多可能破坏主线的功能。
缺点是你必须保持各个分支与主干同步：当功能 A 的分支正在开发时，功能 B 的分支可能已经达到稳定状态并关闭并合并到主干中：在这种情况下，您必须将 B 分支引入的更改从主干合并到 A 分支。 因此，经常将分支与主干合并是一个好习惯，以避免在分支生命结束时出现独特的大合并的问题情况，并需要跟踪和解决大量冲突。
The scenario explained by the thread opener is an example of the feature branches pattern: http://svnbook.red-bean.com/en/1.5/svn.branchmerge.commonpatterns.html#svn.branchmerge.commonpatterns.feature
They are very usefule when you have to keep the main development line (the trunk) stable and you have to develop lots of features that potentially could break the main line.
The downside is that you have to keep the various branches in sync with the trunk: while a branch for feature A is in development, a branch for feature B can have reached a stable status and get closed and merged in the trunk: in this situation, you have to merge the changes introduced by the B branch from the trunk to the A branch. So, it's a good habit to merge often the branches with the trunk to avoid the problematic situation of a unique big merge at the end of the branch life with lots of conflicts to track down and resolve.
每个变更请求的分支听起来有点矫枉过正，而且可能会在以后出现一些麻烦。
尝试将更改请求分组到逻辑区域中，以便您可以看到一组特定的更改对应用程序具有逻辑相关的影响。 为这些创建分支。
我认为这个问题的真正答案是修复客户端。 您需要通过合同明确表明，这些任意的变更请求将花费他们金钱，并且可能会减慢他们的速度。 如果这种情况持续下去，你的 svn 存储库将成为项目中最不麻烦的方面。
A branch for every change request sounds like overkill and maybe some trouble later.
try to group the change requests into logical areas so that you can see that a particular set of changes has a logically related effect on the application. Create branches for these.
I think that the real answer to the question though is to fix the client. You need to make it clear via a contract that these arbitrary change request is going to cost them money and it might slow them down. If this keeps up, your svn repository will be the least troubling aspect of the project.
每个变更请求分支，并相应增加客户端额外管理的成本，是解决此问题的好方法。
在时间、可用于其他功能的资源等方面，这会花费您更多的费用，但由于有很多不相关的更改，或者项目功能被停滞或取消，这可能是更好的方法之一。
这确实与 SCM 系统无关 - 但 Subversion 确实可以满足需要。
Branch per change request, with the corresponding increase in cost to the client for the additional management, is a fine approach for this problem.
It will cost you more, in terms of time, resources available to be working on other features, etc, but with a lot of unrelated changes, or project features that get stalled or canceled, it is probably one of the better approaches.
This is really SCM system agnostic - but Subversion can certainly do what is needed.
每个已测试、工作变更的分支。
每个版本发布的标签。
在主干中开发。
重复。
:)
Branch per tested, working change.
Tag per version release.
Develop in trunk.
Repeat.
:)
每个版本都有一个分支。 将尽可能多的更改组合到一个版本中 - 拥有更多分支通常是好的，在大多数情况下您可以轻松组合它们，将它们分开有点棘手。
为每个版本都有一个分支意味着您还为当前生产中的内容（或者在合并后但实际部署之前版本待定时即将发布的内容）创建了一个分支。
无论如何，这就是我们所做的。
Have a branch for every RELEASE. Combine as many changes into a single release as make sense - having more branches is generally good, you can combine them easily in most cases, breaking them apart is a little more tricky.
Having a branch for every release means you also have a branch for what's currently on production (or what's just ABOUT to be released when releases are pending after the merge but before the actual deployment).
That's what we do anyway.
在我的工作场所，我们有以下系统：
At my workplace we have the following system:
使用 git，我确实为每一个小变化创建一个分支，我喜欢它！
With git, I do make a branch for every little change, and I love it!
当在项目的“实时”分支中进行大量快速更改时，您需要有可靠的代码审查流程以减少破坏它的机会。 代码审查必须在签入之前完成； 并远离该分支的核心开发。
更改获得批准后，您可以签入更改（和/或从工作分支合并）并在完成后创建新的“标签”。
When doing lot of rapid changes in the "live" branch of a project, you need to have a solid code review process to reduce the chance of breaking it. The code review must be done before doing the check-in; and keep away the core development from that branch.
Once the change is approved, you can check-in the change (and/or merge from you working branch) and create a new "tag" once it's done.
当预计时间超过 8 小时时，请使用分支。
When estimated hours are more than 8, use a branch.