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

老实说，SVN分支吓到我了。我所从事的上一个广泛使用它们的项目，我似乎花了一半的时间测试我的分支工作，做一个虚拟合并到主干中，做一个真正的合并-结果发现在我这样做的时候，其他人刚刚承诺了，我不得不更新并重新开始

在那个特定的项目中，每个开发人员都进行了分支。。。有一个主干，然后你有了你的个人分支，完成了一项任务，并将修订的范围合并了回去。这看起来很可怕，因为每次合并分支时都要检查分支中的最后一次修订

---

这个范例真的很好吗？我只是因为不习惯命令行SVN的使用而没有理解它？还是说它是一个糟糕的系统？

老实说，你可能还想使用其他东西，比如git

---

我从未使用过每个开发人员的分支。这个想法对我来说毫无意义

首先，您应该调整您的开发团队，以便人们能够处理源代码的不同部分。如果每个人都在不断编辑相同的文件，那么没有任何技术能够真正帮助您保持每个人的协调

当人们处理相同的文件时，SVN在合并不同人的编辑方面做得很好。编写单元测试以帮助确保合并的代码产品仍然有效

---

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

开发人员分支的问题不是分支本身，而是（正如您自己编写的）合并。不幸的是，合并仍然是svn的一大难题。虽然开发人员分支确实有意义，但工具才是问题所在。我使用git（使用git svn）已经有一段时间了，开发人员分支变得很自然，因为对合并的支持要好得多--您可以直接合并，虽然合并冲突仍然发生，但（根据我的经验），它们发生得更少，痛苦也小得多

这看起来很可怕，因为每次合并分支时都要检查分支中的最后一次修订

---

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

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

---

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

我已经在CVS和SVN上工作了近10年，使用branch per developer也让我感到害怕：）

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

分支由一个开发人员（SVN）或作者（CVS）合并回主干

---

因为合并是日常实践，因为Subversion 1.5很容易实现，所以进行合并应该没有问题。

我认为，合并的主要好处是，每个开发人员都有一个分支，这意味着你可以制定一个频繁签入的策略——当然，让每个人每晚签入代码——不管他们的代码的状态如何，因为他们不会破坏任何其他人的构建，更不用说主开发线了

这意味着您每天晚上都要备份用户的工作，如果开发人员在实现算法时出错或遇到问题，他们更容易恢复到（部分）工作版本

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

---

我同意合并开销可能很繁重，但是如果每个人都在不断地（每周至少几次，最好是一天一次）从主线到他们的分支进行集成，那么从开发人员分支进行合并的影响应该是最小的。

如果你真的需要按开发人员分支进行合并，你应该真正使用Git，它的设计初衷是将每个开发人员的“工作副本”作为自己的存储库进行管理，并将合并构建到核心中。

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

---

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

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

我们根据bug跟踪器工作项进行分支

该策略为开发人员提供了一个独立的源代码控制环境，使每个开发人员都可以使用SVN提供的奢侈品进行编码、还原等操作，但决不允许开发人员在主干中偏离主线太远。不鼓励在主干外发展长期存在的特征。强调bug跟踪工作项的预期范围+持续时间不应明显超过一个工作日，从而强化了这一想法

在实践中，我发现这会导致小变更集相当频繁地合并到主干中。考虑到我的团队规模较小，我们很少在合并过程中互相践踏，因此冲突通常不会出现问题

我要说的是，这个系统在SVN中非常舒适：在TFS中，它似乎不像SVN 1.4那样优雅地处理合并，更不用说1.5+。

对于Subversion，我使用“工作分支”，它由一个团队拥有，并由团队的所有成员共享，如本文所述，如下所示：

我强烈建议大家阅读全文