颠覆实践与多个开发分支

Question

我曾经在联邦部门的网站上工作。我遇到了一个团队领导“杰克”那里领导了一小批开发人员，专门研究C＃，Delphi或PHP等。杰克刚刚在那里登陆了大约2个月，并且通过控制混乱和呈现已经让部门主管感到高兴通过漂亮的表格和图表的进展。

在团队会议上，杰克推广了使用SVN的做法：

1. 每个在同一个项目上工作的开发人员都必须创建一个分支，并且开发人员不应该在主干上工作。
2. 当每个开发人员完成他/她的部分开发工作时，请合并回主干。

杰克命令每个开发人员停止向主干提交代码。这真让我感到惊讶，因为我一直认为分支通常用于发布，错误修复和开发人员实验。我不确定杰克的练习能否真正保护行李箱的完整性。

您如何看待将SVN用于多个开发分支的实践？

请说明您是否使用单元测试以及持续集成。

Answer 1

分支不仅需要发布或实验。当对主干进行如此重大的更改是不切实际的时，它也常用于实现可能影响大量文件的重要功能。通过这种方式，我会说杰克走在正确的轨道上。

然而，在我看来，从不承诺到行李箱的做法可能会有点激烈。小错误修正和更改通常最好提交到主干，在不太可能发生冲突时节省大量额外的合并，并且当其他开发人员必须编写小错误修正时，他们不需要再次分支 / em>与其他当前功能开发分支分开，然后将小修复程序合并回主干。

如果这种分支策略给杰克及其团队带来了成功，他们可能应该坚持下去。

Answer 2

这是一个很好的做法，并且（因此）它将是易于管理的代码（在某种程度上），如果分支名称将遵循一些遵循易于解码的命名规则。

我不同意迈克尔关于快速修复主干的可能性，因为：

• Dura lex，sed lex
• 合并地狱不存在于短期分支机构和长期合并政策
中

Answer 3

免责声明：我充分利用了SVN＆lt; 1.5的经验，因此我对SVN的了解现在可能已经过时了。

Jack想要的是像Git或Mercurial这样的DVCS的默认开发模型。在这个世界上它运作良好。

在我们切换到我们公司的Mercurial之前，我们有了开发 - 一切都在干线模型。这引起了各种令人讨厌的问题，因为我们总是踩到彼此的脚趾，导致真的痛苦的经历。但杰克描述的开发模型听起来像是对这个问题的一个很好的缓解。我不知道这是否也在实践中有效，因为我们在1.5版本发布之前进行了转换（这是他们开始合并跟踪的SVN版本）。但是当合并跟踪现在有效时，它是一个很好的开发模型。

Answer 4

能够为每个开发人员创建一个单独的分支，并且仍然能够在最终合并到trunk之后继续存在，这意味着在几个开发人员特定分支之间代码开发的依赖性非常小。

问题是，开发集成分支对于所有开发人员应该是相同的，这是在本地分支（个别开发人员的个别分支）之后。在这个分支中，开发人员应被授权在每天结束时或在一定时间间隔后更改本地开发分支。