颠覆 - 任何人都应该开发干线吗？

Question

当使用Subversion时,开发人员是否应该在主干上工作,或者主干应仅用于来自每个开发人员分支的合并并由持续集成服务观看？

Answer 1

有两个基本策略:

您使用的在某种程度上是个人偏好的问题.但除了其中任何一个,个别开发人员应该使用分支机构进行自己的实验开发.

像往常一样,没有明确的答案!

BAU是什么意思？ (4认同)
谢谢,尼尔 - 所以在一天结束时,这些选项都不一定是禁止的,更多的是我们想要如何管理开发过程.我倾向于让CI看着行李箱,所以我们保证一个始终可编辑的行李箱,对行李箱进行小的开发,对分支机构进行更大的(待定义的)工作. (3认同)
我工作的公司我遵循选项一,在另一个部门他们遵循第二个策略.我个人更喜欢选项1. (2认同)
关于在分支机构中发展的警告:您推迟与其他分支机构的开发合并.要缓解它,请始终将更改从trunk合并到开发分支中.这就是为什么我提倡在主干中进行开发,并在旧版本上使用分支机构进行紧急修复,以便那些不想升级到最新版本的客户. (2认同)

Answer 2

取决于变化的广泛程度.一般的好习惯是主干应该始终是可编译的,但这并不一定意味着开发人员不能在主干上进行小的更改/错误修正 - 毕竟,这是拥有工作副本的原因之一; 你可以确保在提交之前进行编译.

更大的更改或功能添加应该几乎总是被拉到分支,直到它们准备好集成,以免干扰其他开发.

Answer 3

有许多方法可以使用版本控制系统进行并行开发.你在上面建议的那个没有错 - 但每个都有优点和缺点.我曾在两个方面工作过.

开发主干和切割发布分支是很好的,但如果您需要执行紧急生产版本,则最终必须修补发布分支并再次释放 - 意味着在CI系统中构建分支.

在分支机构中工作并保留主干线(使用持续集成系统进行监控)也很好,但可能会导致多个分支机构的开发人员发生冲突,从而进行更改.

看看以下网站:

它讨论了并行开发的一些分支模式,包括:

Answer 4

我认为这实际上取决于您的操作规模.最多可能有5-10名开发人员进入后备箱应该没问题.但是当然每个人都应该记住,主干需要始终是可编译的.如果他们正在处理一段时间内无法编译的重大变更,那么他们应该转移到分支机构.

@Aiden，您指出的是分布式修订控制系统背后的一大动机。是的，通常您只想在本地工作副本中工作，但您也需要版本控制。如果你想要版本控制，那么Subversion的方式就是在服务器上做一个分支。分布式方式（Mercurial、bzr、git）是允许你在本地创建一个分支。但是，如果您愿意，该分支也可以与其他人共享，或者稍后将完整历史记录上传到中央服务器（如果您有的话）。 (2认同)

Answer 5

使用Subversion时,每个人都可以在干线上工作.如果某个特定开发人员正在处理大型或"实验性"功能,那么为该工作创建一个单独的分支是明智的,可以稍后将其合并回主干.

虽然,您描述的方法,每个开发人员都有自己的分支,但是比Subversion 更接近Git.如果这是您喜欢的工作方式,我强烈建议您使用Git.

使用Git,没有必要使用某种连续集成服务器来观察单独的分支.相反,每个开发人员都有自己的分支,只要他们想要,他们就可以将其合并回主分支.