在项目中使用主干、分支和标签
我知道这个理论，但是从项目的实际角度来看，svn 是如何使用的呢？假设我有一个网站，其中的功能将被修改或添加。在什么情况下会使用新的主干、分支和标签？
I know the theory but how is svn used from a practical point of view for a project? Say, I have a web site with features that are going to be modifed or added. In what cases would new trunks, branches and tags be used?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我想说的是，进行“稳定”的非常小的更改（也许是小错误修复）的单个主干，不会破坏您的构建。
应该为新功能/大的变化创建分支。在分支运行期间，分支应及时了解主干的更改。
新功能完成后，应将分支合并回主干，然后可以删除该分支。
标签用于发布。例如v1.2
I'd say a single trunk where "stable" very minor changes (perhaps small bug fixes) are made, that will not break your build.
Branches should be made for new features / large changes. The branch should be kept up to date with changes to your trunk, whilst the branch is in operation.
Once your new feature has been completed the branch should be merged back into the trunk and then the branch can be deleted.
Tags are for releases. e.g. v1.2
我的拙见：合并分支是可怕的。在许多情况下，不同开发人员所做的更改是完全独立的，因此可以顺利合并。但在任何繁忙的项目中，有时都会发生变更冲突。如果幸运的话，SVN 会识别冲突并在合并时给出错误。如果你不那么幸运，SVN 不会捕获它，但它无法编译。不管怎样，现在必须有人弄清楚如何将这些变化整合在一起。有时这是显而易见且容易的。但我有很多次不得不让进行更改的开发人员一起讨论，这样我们才能弄清楚该怎么做。
如果您非常不幸，SVN 和编译器都不会发现问题，冲突的更改会进入生产环境，并且程序会出现错误行为。
根据这一观察，我得出两个结论： (a) 尽可能少地建立分支。或者更准确地说，制定策略以尽可能少地进行合并。 (b) 在代码仍在测试时进行合并。
有一段时间，我的公司有一个分支策略，即每个项目都有自己的分支，在该分支上进行测试，当我们准备好部署到生产时，我们合并了要包含在该版本中的所有分支，编译并部署。事实证明这是一个非常非常糟糕的主意。有人会在部署前一天尝试解决合并冲突，并且合并的结果从未经过测试。许多细微的错误潜入生产中。
有一段时间我们使用了这个策略：大多数开发都是在主干中完成的。当一个版本准备好移交给测试组时，我们会为其剥离一个分支。然后在主干中继续进行下一个版本的工作。当前版本的任何错误修复都是在分支中完成的，并且该分支中的更改会定期合并回主干。有时需要同时进行 3 个版本的工作，即一个版本正在测试，另一个版本即将准备好进行测试，现在我们需要开始下一个版本。在这种情况下，我们将拥有当前版本的测试分支、主干以及下一个版本的“预”分支。当当前版本进入测试组时，我们会将“pre”分支合并到主干中，它成为当前版本。
我们最近开始尝试一种略有不同的策略。当某个版本处于测试阶段时，我们仍然会为其剥离一个单独的分支。但是测试出来的任何修复都是在主干中进行的，然后这些修复从主干合并到测试分支中。这意味着所有开发都发生在主干中，并且合并总是从主干到其他地方。这有两大优点：第一，开发人员总是使用 trunk 进行测试，因此我们对 trunk 中的代码是好的有更高的信心。测试组将针对发布分支进行测试，因此我们有信心发布分支是好的。也就是说，我们有信心这两个分支都会受到测试。当您在分支中进行更改然后合并回主干时。几乎无法保证任何人都会测试合并的结果。第二，主干总是有每个模块的完整“指责”历史。当您从分支合并回主干时。 trunk 中的历史记录将分支中的所有更改归因于进行合并的人，而不是真正进行更改的人，并且注释往往是无信息的“从分支 xyz 合并”。当您从主干合并到分支时，确保分支现在显示“错误”的人员和无信息的注释，但主干有良好的历史记录。有一个地方可以去寻找历史，而不是试图追寻分支。
My humble observations: Merging branches is scary. In many cases, changes made by different developers are completely separate and so merge smoothly. But in any busy project, there are going to be times when changes conflict. If you're lucky, SVN recognizes the conflict and gives you errors at merge times. If you're less lucky, SVN doesn't catch it but it fails to compile. Either way, somebody now has to figure out how to put the changes together. Sometimes this is obvious and easy. But I've had many times where I've had to get the developers who made the changes together so we could figure out what to do.
If you're very unlucky, neither SVN nor the compiler see a problem, conflicting changes go to production, and the program behaves incorrectly.
From this observation I come to two conclusions: (a) Make as few branches as possible. Or more accurately, develop your strategy to do as few merges as possible. And (b) Do merges on code while it is still in testing.
For a while my company had a branching strategy that said that each project got its own branch, tested off of that branch, and when we were ready to deploy to production, we merged all the branches to be included in that release, compiled and deployed. This turned out to be a really really bad idea. Somebody would be trying to resolve merge conflicts the day before deploying, and the results of the merge were never tested. A lot of subtle bugs crept into production.
For a whlie we used this strategy: Most development is done in trunk. When a release is ready to be turned over to the test group, we peel off a branch for it. Then work on the next release proceeds in trunk. Any bug fixes to the current release are done in the branch, and the changes in this branch are periodically merged back into trunk. Occassionally it was necessary to have work on 3 releases going on simultaneously, i.e. one release was in testing, another was getting close to being ready for testing, and now we need to start on the next release. In that case we'd have the test branch, trunk for the current release, and a "pre" branch for the next release. When the current release went to the test group, we would then merge the "pre" branch into trunk and it became the current release.
We have recently begun experimenting with a slightly different strategy. When a release is in testing, we still peel off a separate branch for it. But any fixes coming out of testing are made in trunk, and then those fixes are merged from trunk into the test branch. This means that all development happens in trunk, and merges are always from trunk to somewhere else. This has two big advantages: One, developers are always testing with trunk, so we have a higher confidence that the code in trunk is good. The testing group will test against the release branch, so we have confidence that the release branch is good. That is, we have some confidence that both branches will be tested. When you make changes in a branch and then merge back to trunk. there's little assurance that anyone will test the results of that merge. Two, trunk always has the full "blame" history of every module. When you merge from branches back to trunk. the history in trunk attributes all changes from the branch to the person who did the merge, rather than the person who really made the change, and the comment tends to be an uninformative "merged from brach xyz". When you merge from trunk to a branch, sure the branch now shows the "wrong" person and an uninformative comment, but trunk has a good history. There's one place to go for history instead of trying to chase down branches.
不同的组织做的事情非常不同。上面Alex给出的解决方案是一种常见的解决方案，但是它遇到了一个问题，就是当你登陆你的分支后，你才会发现其他分支与你的冲突。这导致人们不得不调试他们一段时间没有看过的内容中的冲突。
我遇到的另一种常见方法是在主干中进行所有开发，并让开发人员进行所有小型、独立的提交。有多种方法可以添加功能并使其默认不可见，但在开发副本中打开。使用它们。这种方法需要开发人员的关注，但可以避免管理寿命较长的分支之间的冲突带来的痛苦。
许多使用 Alex 解决方案的人都会跳上跳下说：“这对小团队之外的任何事情都不起作用！”对此我的回答是，小团队没有什么问题，他们的生产力通常远远超过大团队所能做到的。如果开发人员有纪律，那么该策略就可以扩展，例如谷歌就使用它。如果您想查看使用该策略的实际项目，请查看 http://llvm.org/。
以及一些建议。如果你想遵循 Alex 的策略，我强烈建议使用 git 而不是 svn。它比 svn 更好地处理分支。如果您想遵循我建议的策略，并且您的团队不是一个由您信任的人组成的小团队，那么您需要使用代码审查工具，例如 http://code.google.com/appengine/articles/rietveld.html 以减少可能出现的明显问题。
Different organizations do very different things. The solution that Alex gives above is a common one, however it encounters the issue that you'll only discover what other branches have conflicts with yours after you land your branch. This causes people to have to debug conflicts in stuff that they have not looked at in some time.
The other common approach that I have encountered is to do all development in trunk, and make developers make all commits small, standalone, commits. There are a variety of ways to add a feature and make it invisible by default, but turned on in your development copy. Use them. This approach requires care from the developers, but avoids pain from managing conflicts between longer lived branches.
A lot of the people who use Alex' solution will jump up and down and say, "That will never work for anything beyond a tiny team!" To that I respond that there is nothing wrong with small teams, their productivity typically far exceeds anything a large team can do. And that strategy can scale if developers have discipline, for instance Google uses it. If you want to see an actual project that uses that strategy, take a look at http://llvm.org/.
And some advice. If you want to follow Alex' strategy, I strongly recommend using git instead of svn. It handles branches much better than svn does. If you want to follow the strategy that I suggest and your team is not a small team with people you trust, you need to use a code review tool like http://code.google.com/appengine/articles/rietveld.html to reduce the obvious problems that can arise.
看看这两篇文章：
http://www.snuffybear.com/ucm_branch.htm
http://www.vance.com/steve/perforce/Branching_Strategies.html
来自 SnuffyBear 的链接更多地讲述了您似乎想要采用的策略，而 其他文章讨论了其他策略，例如按发布分支。每篇文章都概述了每种策略的优点和缺点。
Have a look at these two articles:
http://www.snuffybear.com/ucm_branch.htm
http://www.vance.com/steve/perforce/Branching_Strategies.html
The the link from SnuffyBear speaks more about the strategy that you seem to want to employ whereas the other article talks about other strategies such as branch by release. Each article outlines the advantages and disadvantages of each strategy.