颠覆 – 任何人都应该发展的主干？
在使用Subversion的时候，开发者应该干什么呢？还是应该把干线用于每个开发者分支的合并，并由持续集成服务来观察？
有两个基本的策略：
- 不稳定的干线 – 干线总是包含最新的代码，分支做的发布
- 稳定的中继线代码是在分支机构开发的，只有在从中继线完成testing和释放的情况下才能检查到中继线
你使用的是一定程度上的个人偏好问题。 但是，除了这些之外，个别开发者应该使用分支来进行自己的实验开发。
像往常一样，没有明确的答案！
取决于改变的程度。 一个好的做法是，trunk应该总是可以编译的，但是这并不意味着开发人员不能在trunk上进行小的修改/修正 – 毕竟这是创build工作副本的原因之一。 你可以确保在提交之前进行编译。
更大的变化或function增加应该几乎总是被拉到分支，直到他们准备集成，以免干扰其他发展。
有许多方法可用于并行开发的版本控制系统。 上面提出的build议没有任何问题，但每个build议都有其优点和缺点。 我已经在两个方面工作。
发展树干和切割释放分支是好的，但如果你需要执行紧急生产释放，你最终不得不修补释放分支，并再次释放 – 意味着在你的CI系统build立一个分支。
在分支机构工作并保留主干线（使用持续集成系统进行监控）也很好，但是可能会导致与多个分支机构的开发人员发生冲突问题。
还请看下面的网站：
http://www.cmcrossroads.com/bradapp/acme/branching/
它讨论了并行开发的一些分支模式，包括：
- S1。 主线
- S2。 并行维护/开发
- S3。 重叠版本
- S4。 对接线
- S5。 分阶段积分线
- S6。 更改传播队列
- S7。 第三方Codeline
- S8。 内/外线
我认为这取决于你的经营规模。 大概5-10个开发者，每个人都应该干什么就行了。 但是，当然每个人都应该记住，主干需要始终可编译。 如果他们正在进行一些暂时不能编译的重大更改，那么他们应该转移到一个分支。
在使用Subversion的时候，每个人都可以使用Subversion， 如果一个特定的开发人员正在开发一个大型的或“实验性”的function，那么为这个工作创build一个单独的分支是明智的，这个分支可以在之后被合并回主干。
虽然，你所描述的方法，每个开发人员有自己的分支，比Subversion更接近Git 。 如果这是你喜欢的工作方式，我强烈推荐使用Git。
使用Git，没有必要使用某种持续集成服务器来观察单独的分支。 相反，每个开发人员都有自己的分支，只要他们愿意，他们可以重新合并回主分支。
我几乎总是在干线上开发的团队工作 – 工作正常。 我并不是说这是最好的主意或任何东西，只是不是那些值得反对的东西，如果它会让你被解雇。
但是，我们的系统总是可以build立的，而且经常使用CI。 每个开发人员都必须知道更新/重build/重测/提交循环（不是简单，但它工作得很好）。
哼，当我想到我们有多less软件实践“足够好”的时候，它会很痛苦。
有一个论点是应该要求开发者在trunk上工作。
如果让他们分支，有些人会试图无限期地维护这些分支，并定期与主干交叉同步。 这将不可避免地导致复杂的合并操作，而这些又会产生错误。
通过强制所有人进入主干，他们必须保持非常接近头部的状态，所以错误合并引入错误的风险就会降低。 而且，由于每个人都运行最新的代码，他们更容易发现错误，并且修复会更快。
当然，有时候一个大特征需要单独进行，但在这种情况下，可以做出特别批准的例外。
我们的主干只是合并和修复紧急程度的问题。 当我们有一个新的项目时，我们分支干线，在分支上进行开发，如果其他分支合并到干线中，则从干线分叉，当我们准备testing时，我们部署分支。 当testing正常时，我们合并到主干，并释放到testing版。 在合并之前，我们在主干上做一个版本来避免问题。
testing版确定后，我们发布到产品。
我正在使用我们产品的3.0版本，并将代码更改检入到主干中。 发布还有几个星期。
一个同事正在尝试一些function，可能会使其成为4.0，但绝对不是3.0。 她正在检查她的东西到一个单独的分支。 把这种东西放入后备箱是不对的。
另一位同事正在修复2.5版本中的错误，我们已经把这个错误发给了客户。 他正在检查他们进入2.5分支，原因很明显。
因此，要回答标题问题（每个人都应该发展的主干，我的答案是否定的
PS关于合并。 我们可以有select地将2.5分支的一些东西合并到树干中，而不是从树干回到分支。 主干和4.0分支之间的合并可以双向进行。
正如尼尔·巴特沃斯（Neil Butterworth）所说的那样 ， 存在几种有效的方法。
不过，我个人build议有一个稳定的行李箱，并在临时分行做所有的重大发展。 （也就是说，只有一个小小的，独立的变化，完全可以通过一次提交就可以直接进入主干。）为了避免寿命较长的分支离主线太远，（自动）将所有进入主干的东西合并到所有的开发分支机构，至less每天。 哦， 一切都应该由CI来监视 – 不仅仅是主干，还有所有的开发分支。 特别是哈德森，这是一个很好的解决scheme，并且导致很less的开销。
如果对我们如何应用这个感兴趣， 这个答案还有更多的细节。 （我不想重复自己太多… 🙂
我实际上推荐这种方法，即使它只是一个团队工作的代码库， 即使每个人都在做同样的function/改变。 为什么？ 那么，因为根据我的经验（除非发布时间表，要求等事情 – 在您的环境中是非常可预测的），那么绝对会让您的行李箱始终处于可释放状态 。
我有开发人员创build项目分支或更改请求/ bug分支，然后合并回来，所以在某种程度上，我有开发人员工作，但“合并”分支是通过一些build-控制工具或过程。
我认为这个问题已经很好的涵盖了
是的，这应该是你的发布工作副本。 你所有的分支都应该是以前版本的代码。
这完全取决于你的发布时间表。 如果所有正在进行定期检查的工作都是立即释放的，那么它们都可以被检查到一个区域，如后备箱。 如果有一些工作会被阻止，而另一些工作（如尚未完成的工作）必须先出去，那么第一个出去的代码就可以交给中继线，而下一个代码就在自己的分支中，反之亦然。
你会发现合并和刷新分支可能是偶尔出错的麻烦。 所以自然而然地想尽量减less这是有道理的。 源代码pipe理的总体思路是每个人都可以在一个地方工作。
通常情况下，当你得到更大的团队时，发布计划是由子团队和他们的项目组织的，而且他们有自己的分支机构。
是。
使你的最新版本成为你最近的版本没有任何意义。 那么，你的树干在树枝上已经过时了。
我认为，如果你敏捷，在几个星期内以小幅增长释放，你应该在树干中发展。 这样，你有最新的行李箱，它不断build成，可能会被破坏，但很快就会得到解决，当你准备好发布，标记并释放它。 这样，分支也没有合并的麻烦。
我想我还想补充一点，如果你在分支机构开发，你就不会变得敏捷。 在分支机构开展工作只在瀑布。
我认为你使用的工具也是一个很重要的因素。
- 如果你使用的是Subversion，不稳定的主干可能会对你更好。
- 如果你使用GIT，稳定的中继将比Subversion容易得多。
在我的公司，我们采用了稳定的主干开发模式，代码正在开发，并在合并到主干之前在分支机构进行了全面testing。 但是我发现这种做法非常令人生畏，因为validation团队经常需要几个月才能完全testingfunction分支。 所以我们最终会把这些分支徘徊几个月，然后才能把它们合并到主干中。
这样做的另一面是使用不稳定的主干开发，所有的变化都会一直进入主干，但是我们的validation团队开始抱怨他们对代码没有信心，因为每个人的变化总是在那里，没有隔离。
所以似乎这两种方法都不是最佳的。 对于validation可能需要很长时间的团队，是否有更优化的方法？
