SVN：每个开发人员的个人分支？
老实说，SVN 分支让我感到害怕。我从事的最后一个项目广泛使用了它们，我似乎花了一半的时间来测试我的分支的工作，进行虚拟合并到主干，进行真正的合并 - 却发现在我这样做时其他人刚刚提交了并且我必须更新并重新开始。
在那个特定的项目中，分支是每个开发人员完成的......有一个主干，然后你有你的个人分支，处理一个任务并将修订范围合并回来。这看起来很可怕，因为你每次都必须检查什么您分支中的最后一个修订是您合并的。
这个范例真的很好吗，但我只是不明白它，因为我不习惯命令行 SVN 使用？或者这是一个糟糕的系统？
I'll be honest, SVN branches scare me. The last project that I worked on which used them extensively, I seemed to spend half my time testing my branch worked, doing a dummy merge into trunk, doing a real merge - only to find someone else had just committed while I was doing this and I had to update and start over.
On that particular project, branching was done per-developer... there was a trunk and then you had your personal branch, worked on a task and merged the range of revisions back in. It seemed horrific as you had to check each time what the last revision in your branch was that you merged.
Is this paradigm actually good, and I just didn't get it since I'm not used to command-line SVN usage? Or was it a terrible system?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（14）
对于 Subversion，我使用“工作分支”，该分支由团队拥有并由团队的所有成员共享，如伟大的 多个敏捷团队的版本控制文章，如下所示：
我强烈建议阅读整篇论文，它确实值得一读。
对于 Subversion 之外的其他东西，我可能会考虑使用“功能分支”，但是，说实话，我不认为每个开发人员的个人分支有什么意义（并且超出功能的粒度对我来说没有意义） ）。
With Subversion, I use "work branch(es)" which are owned by a team and shared by all members of the team as described in the great Version Control for Multiple Agile Teams article and illustrated below:
I warmly recommend to read the whole paper, it's really worth the read.
With something else than Subversion, I may consider using "feature branches" but, to be honest, I don't see the point of personal branches per developer (and it doesn't make sense to me to go beyond the granularity of a feature).
我从未使用过每个开发人员分支。这个想法对我来说没有意义。
首先，您应该协调您的开发团队，以便人们倾向于处理源代码的不同部分。如果每个人都不断地编辑相同的文件，则任何技术都无法真正帮助您保持每个人的协调。
当人们在同一文件上工作时，SVN 在合并不同人的编辑方面做得很好。编写单元测试以帮助确保合并的代码产品仍然有效。
我使用分支来维护当前发布的代码版本，同时开发下一个版本。
I have never used branch-per-developer. The idea doesn't make sense to me.
To begin with, you should align your development team so that people tend to work on different parts of the source code. If everyone is constantly editing the same files, no technology will really help you keep everyone coordinated.
SVN does a great job of merging different people's edits for those times when people do work on the same files. Write unit tests to help ensure the merged code product still works.
I use branches to maintain the currently released version of the code while developing the next version.
每个开发人员分支是一个有效的范例。我发现的主要好处是它们允许您检查正在进行的工作，因此可以对其进行备份，以便其他人在您生病时访问等，而不会扰乱主干。
分支本身并不是真正的问题，问题在于管理合并。我过去所做的是使用合并令牌（毛绒玩具或动作玩偶效果很好 - 持有令牌的人可以合并到主干）或在开发维基上有合并队列，基本上只有一个开发合并到一次树干。
Per developer branches are a valid paradigm. The primary benefit I found was they allow you to check in work in progress and therefore get it backed up, accessed by others in case you're off ill etc without upsetting the main trunk.
Branches themselves are not really an issue, the problems are managing the merges. What I've done in the past is use a merge token (soft toy or action figure works well - he who holds the token can do the merge to trunk) or have merge queue on the dev wiki, basically have only one dev merging into trunk at a time.
在我看来，每个开发人员拥有一个分支的主要好处是，您可以制定频繁签入的政策 - 当然让每个人每晚签入代码 - 无论他们的代码状态如何，因为他们不会破坏其他人的构建，更不用说主线发展了。
这意味着您可以每晚备份人们的工作，并且如果开发人员在算法的实现中犯了错误或遇到问题，则可以更轻松地恢复到其开发的（部分）工作版本。
它还将确保只有经过完全批准和测试的代码（假设您正在进行代码审查和单元测试）才会被签入主线。
我同意合并开销可能会很繁重，但是如果每个人都不断地（每周至少几次，最好每天一次）从主线集成到他们的分支，那么从开发人员分支合并的影响应该是最小的。
The main benefit, as I see it, from having a branch per developer is that you can institute a policy of frequent checkins - certainly having everyone checkin code every night - regardless of the state of their code as they won't break anyone else's build, let alone the main development line.
This means that you have a nightly back up of peoples work, and it's easier for the developer to revert back to a (partially) working version of their development if they make a mistake or hit a problem with their implementation of an algorithm.
It will also ensure that only fully approved and tested code (assuming you are doing code reviews and unit testing) gets checked into the main line.
I agree that the merging overhead could be onerous, but if everyone is constantly (well at least a couple of times a week, preferably once a day) integrating from the main line to their branch the impact of merging from the developer branch should be minimal.
我只是想指出，您不再需要这样做：SVN 1.5.0 及更高版本支持合并跟踪。
I just wanted to point out that you no longer have to do this: SVN 1.5.0 and up support merge tracking.
老实说，您可能想要其他东西，比如 git。
http://git-scm.com/
To be honest, you probably want to something else, like git.
http://git-scm.com/
我过去也使用过类似的做法。
如果多个开发人员都更新相同的代码文件，则可能不是版本控制问题。我对你的代码一无所知，但会不会是它太单一并且不够模块化？这样，当分配任务时，开发人员就不会总是踩到彼此的更改。
I've used a similar practice in the past.
If multiple developers are all updating the same code files, it may not be a version control problem. I don't know anything about your code, but could it be that its too monolithic and not modular enough? That way, when the assignments are doled out, the developers are not always stepping on each others changes.
我已经使用 CVS 和 SVN 近 10 年了，使用每个开发人员分支也让我感到害怕:)。
我工作过的所有团队都使用主干进行日常开发，使用分支进行冻结/测试/发布版本（有时大型新的独立功能是在单独的分支中实现的）。
分支由开发人员之一 (SVN) 或作者 (CVS) 合并回主干。
而且由于从 Subversion 1.5 开始合并就成为日常实践，因此合并应该没有问题。
I've been working with CVS and SVN for almost 10 years and using branch per developer scares me too :).
All teams in which I was working used trunk for daily development and branches for frozen/beta/release version (sometimes large new, independent features were implemented in the separate branch).
Branches were merged back to trunk by one of developers (SVN) or by author (CVS).
And because merge as daily practice since Subversion 1.5 is easy there should be no problem to do a merge.
开发人员分支的问题不是分支本身，而是（正如您自己编写的）合并。不幸的是，使用 svn 进行合并仍然很痛苦。虽然开发人员分支确实有意义，但工具才是问题所在。我使用 git（与 git svn）已经有一段时间了，开发人员分支变得很自然，因为对合并的支持方式更好——你可以只合并，虽然合并冲突仍然发生，但它们是（根据我的经验）发生的事情要少得多，痛苦也少得多。
The problem with developer branches is not the branches itself but (as you wrote yourself) merging. Unfortunately merging is still a pain with svn. While developer branches do make sense the tool is the problem. I'm using git (with git svn) since a while now and developer branches just become natural because the support for merging is way better -- you can just merge, and while merge conflicts still happen they are (from my experience) happening much less and are much less painful.
如果您确实需要为每个开发人员创建分支，那么您应该真正使用 Git，它是从头开始设计的，旨在将每个开发人员的“工作副本”作为其自己的存储库进行管理，并且合并内置于其核心中。
If you really need to do per-developer branches, you should really use Git, it is designed from the ground up to manage every developers "working copy" as a repository of its own and merging is built into the core of it.
我在 SVN 中为我的上一个团队（小型团队：当前有 4 个开发人员）使用了类似的分支策略，并在我当前的团队中采用了 TFS 中的方法。
我们按错误跟踪器工作项进行分支。
这种策略为开发人员提供了一个独立源代码控制环境的每个开发人员分支的好处，他可以使用 SVN 提供的奢侈品来编写代码、恢复等，但绝不允许开发人员偏离目标太远。主干线。在主干之外开发长期存在的功能是非常不鼓励的。通过强调错误跟踪工作项目的预期范围和持续时间不应显着超过一个工作日来强化这一想法。
在实践中，我发现这会导致小的变更集被相当频繁地合并到主干中。考虑到我的团队规模较小，我们很少会为了合并而互相踩脚，因此冲突通常不会成为问题。
我想说的是，这个系统在 SVN 中相当舒适：在 TFS 中则不然，TFS 似乎无法像 SVN 1.4 那样优雅地处理合并，更不用说 1.5+ 了。
I've used a similar branch strategy in SVN on my last teams (small teams: current is 4 devs large) and have adopted the approach in TFS on my current team.
We branch per bug tracker work item.
This strategy provides the branch-per-developer benefit of an isolated source control environment for the developer where (s)he can bang away on code, revert, etc. using the luxuries SVN provides but never allows the developer to drift too far from the mainline in trunk. The development of long-standing features outside the trunk is quite discouraged. The idea being reinforced by stressing that the intended scope + duration of a bug tracking work item should not significantly exceed one business day.
In practice, I've found this results in small changesets being merged into the trunk fairly frequently. Given the small nature of my teams, we're rarely stomping on each others' feet getting a merge down so conflicts aren't typically problematic.
I will say, this system was quite comfortable in SVN: less so in TFS which doesn't seem to handle merges as gracefully as SVN 1.4 even, let alone 1.5+.
尝试使用 Mercurial。它的设计没有中央存储库。
也没有提交冲突，因为没有推送。
Try using Mercurial. It does not have central repository by design.
There are no commit conflicts too, because there is no push.
您的范例需要适合该工具的亲和力。 Subversion 是该范例的错误工具，因为 Subversion 中的合并是 PITA。更改您的范例或切换到 Git 或 Mercurial。
Your paradigm needs to fit the affinity of the tool. Subversion is the wrong tool for that paradigm because merging in Subversion is a PITA. Change your paradigm or switch to Git or Mercurial.
我们使用单个开发分支来进行大多数日常操作。我们通过经验了解到，当一个开发人员正在开发一个扩展多个模块的大型项目时，他应该创建自己的分支并以此为基础进行工作。否则，我们从单个 svn 分支运行不会遇到任何问题，并且它大大简化了事情。需要注意的是，我们有一个由 3 名开发人员和偶尔的承包商组成的小团队。
We use a single development branch for most day-to-day operations. We've learned through experience that when one developer is working on a really large project that expands multiple modules, he should create his own branch and work from that. Otherwise, we haven't had any problems running from a single svn branch, and it greatly simplifies things. Caveat, we have a small team of 3 developers + the occasional contractor.