SVN：每个开发人员的个人分支机构？

Question

老实说，SVN分支机构吓唬我了。我工作的最后一个项目广泛使用它们，我似乎花了一半的时间来测试我的分支工作，做一个虚拟合并到主干，做一个真正的合并 - 只是为了找到其他人刚刚做了这个和我不得不更新并重新开始。

在那个特定的项目中，分支是由每个开发人员完成的...有一个主干然后你有了你的个人分支，处理任务并合并了一系列修订版本。看起来很可怕因为你必须检查每次你的分支中的最后一个修订是你合并的。

这个范例实际上是不错的，我只是没有得到它，因为我不习惯命令行SVN使用？或者这是一个糟糕的系统？

Answer 1

使用Subversion，我使用“工作分支”，该工作分支由团队拥有并由团队中所有成员共享，如伟大的Version Control for Multiple Agile Teams文章所述，如下所示：

我热烈建议阅读整篇论文，这真的值得一读。

除了Subversion以外的东西，我可能会考虑使用“功能分支”，但说实话，我没有看到每个开发人员的个人分支点（对我来说超出粒度是没有意义的特写）。

Answer 2

我从未使用过分支机构。这个想法对我没有意义。

首先，您应该与开发团队保持一致，以便人们倾向于处理源代码的不同部分。如果每个人都在不断编辑相同的文件，那么任何技术都无法真正帮助您保持每个人的协调。

当人们对同一文件进行操作时，SVN可以很好地合并不同人的编辑。编写单元测试以帮助确保合并的代码产品仍然有效。

我在开发下一个版本时使用分支来维护当前发布的代码版本。

Answer 3

每个开发者分支都是有效的范例。我发现的主要好处是，它们允许您检查正在进行的工作，从而将其备份，其他人访问以防您生病等，而不会扰乱主干。

分支机构本身并不是真正的问题，问题在于管理合并。我过去所做的是使用合并令牌（软玩具或动作人物效果很好 - 持有令牌的人可以合并到主干）或者在开发维基上有合并队列，基本上只有一个开发合并到一次干。

Answer 4

  

这似乎很可怕，因为每次必须检查分支中的最后一个修订是否合并。

我只是想指出你不再需要这样做：SVN 1.5.0及以上支持合并跟踪。

Answer 5

正如我所看到的，每个开发人员拥有一个分支机构的主要好处是，您可以制定频繁签入的策略 - 确保每个人每晚都检查代码 - 无论代码状态如何，因为它们不会破坏别人的建设，更不用说主要的开发线了。

这意味着您每晚都会对人们的工作进行备份，如果开发人员犯了错误或者他们的算法实现出现问题，那么开发人员更容易恢复到他们开发的（部分）工作版本

它还将确保只有经过完全批准和测试的代码（假设您正在进行代码审查和单元测试）才会进入主线。

我同意合并开销可能很繁重，但是如果每个人都经常（至少每周一次，最好每天一次）从主线到他们的分支整合来自开发者分支的合并的影响应该是最小的。

Answer 6

说实话，你可能想要别的东西，比如git。

http://git-scm.com/

Answer 7

我过去曾经使用过类似的做法。

如果多个开发人员都在更新相同的代码文件，则可能不是版本控制问题。我对你的代码一无所知，但可能是它太单一而且不够模块化？这样，当分配完成后，开发人员并不总是踩着彼此的变化。

Answer 8

我已经使用CVS和SVN近10年了，每个开发人员使用分支也吓到我了。）。

我工作的所有团队都使用trunk进行日常开发，使用分支进行冻结/ beta /发布版本（有时候大型新的独立功能在单独的分支中实现）。

分支机构由开发人员（SVN）或作者（CVS）合并回主干。

因为自Subversion 1.5以来合并为日常练习很容易，所以合并应该没有问题。

Answer 9

如果你真的需要做每个开发人员的分支机构，你应该真正使用Git，它是从头开始设计的，以管理每个开发人员“工作副本”作为自己的存储库，并且合并内置于它的核心

Answer 10

开发人员分支的问题不是分支本身，而是（正如你自己写的那样）合并。不幸的是合并仍然是svn的痛苦。虽然开发人员分支确实有意义，但工具是问题。我现在使用git（使用git svn）和开发人员分支只是变得自然，因为合并的支持是方式更好 - 你可以合并，而合并冲突仍然发生，他们是（根据我的经验）发生的事情少得多，痛苦也少得多。

Answer 11

我在上一个团队中使用了类似的SVN分支策略（小团队：当前是4个开发人员），并在我现有团队的TFS中采用了这种方法。

我们为每个bug跟踪器工作项进行分支。

这个策略为开发人员提供了一个孤立的源代码控制环境的开发优势，他可以使用SVN提供的奢侈品来解决代码，还原等等，但是从不允许开发人员漂移远离干线主线。在行李箱外面开发长期特征是非常气馁的。通过强调错误跟踪工作项的预期范围+持续时间不应超过一个工作日来加强这一想法。

在实践中，我发现这会导致小变更集被频繁合并到主干中。鉴于我的团队性质很小，我们很少会在彼此的脚下踩踏合并，因此冲突通常不会产生问题。

我会说，这个系统在SVN中非常舒服：在TFS中不那么好，它似乎不像SVN 1.4那样优雅地处理合并，更不用说1.5 +了。

Answer 12

尝试使用Mercurial。它没有设计中央存储库。

也没有提交冲突，因为没有推送。

Answer 13

您的范例需要符合该工具的亲和力。 Subversion是该范例的错误工具，因为在Subversion中合并是一个PITA。改变你的范例或切换到Git或Mercurial。

Answer 14

我们使用单个开发分支进行大多数日常操作。我们通过经验了解到，当一个开发人员正在开发一个扩展多个模块的大型项目时，他应该创建自己的分支并从中开展工作。否则，我们从单个svn分支运行没有任何问题，它大大简化了事情。警告，我们有一个由3名开发人员组成的小团队+偶尔的承包商。