颠覆——是否有人会在主干上发展?

有两种基本策略:

• 不稳定的主干-主干始终包含最新的代码,分支用于执行发布
• 稳定的主干代码是在分支中开发的,只有在对主干进行完全测试和释放时才会签入主干中。

在某种程度上,你使用的是个人喜好的问题。 但是除了这些之外,单个开发人员应该使用 为自己的实验发展提供分支。

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

取决于变化的程度。一个一般的好实践是主干应该始终是可编译的,但这并不一定意味着开发人员不能在主干上进行小的更改/错误修复——毕竟,这是拥有一个可工作的副本的原因之一;您可以确保某些东西可以编译 之前 提交它。

更大的更改或特性添加应该几乎总是被拉入分支,直到它们准备好进行集成,以免干扰其他开发。

有许多方法可以用于并行开发的版本控制系统。你上面的建议没什么错,但每一个都有利弊。我在这两方面都工作过。

开发主干和切断发布分支是可以的,但是如果您需要执行紧急生产发布,那么最终必须修补发布分支并再次发布它——这意味着在您的CI系统中构建一个分支。

在分支中工作并保留主主干(使用持续集成系统进行监控)也很好,但可能导致与多个分支中的开发人员进行更改的冲突问题。

还可以查看以下站点:

http://www.cmcrossroads.com/bradapp/acme/branching/

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

• S1主线
• S2。并行维护/开发
• S3重叠释放
• S4。对接线
• S5。阶段集成线
• S6。更改传播队列
• S7第三方代码行
• S8。内线/外线

我认为这真的取决于你的业务规模。多达5-10个开发人员承诺使用主干应该是正常的。当然,每个人都应该记住,主干需要始终是可编译的。如果他们正在处理暂时无法编译的主要更改,那么他们应该转移到一个分支。

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

尽管如此,您描述的方法(每个开发人员都有自己的分支)更接近于 Git 而不是颠覆。如果这是您喜欢的工作方式,我强烈建议您改用git。

对于Git,不需要使用某种连续集成服务器来监视单独的分支。相反,每个开发人员都有自己的分支,只要他们愿意,就可以将其合并回主分支。

我几乎总是在开发主干的团队中工作——工作得很好。我并不是说这是最好的主意,也不是说如果你想被炒鱿鱼的话,这是不值得反对的。

然而,我们的系统总是可构建的,并且经常使用CI。每个开发人员都必须知道更新/重建/重新测试/提交周期(不是很简单,但它工作得很好)。

嗯,当我想到我们有多少软件实践“足够好”时,我会很伤心。

有一种观点认为开发人员应该被要求在主干上工作。

如果您让它们分支掉,一些分支将倾向于无限期地维护这些分支,并定期与主干交叉同步。这将不可避免地导致复杂的合并操作,而这些操作又会产生错误。

通过强迫每个人都上主干,他们必须保持非常接近头部,这样就减少了错误合并引入的风险。此外,由于每个人都运行最新的代码,他们更可能在错误蔓延时注意到它们,并且修复程序将更快地提交。

当然,有时一个大的特性需要单独分阶段进行,但是在这些情况下,可以作出一个特别批准的异常。

我们的主干只用于合并和修复紧急错误。当我们有一个新的项目时,我们对主干进行分支,在分支上进行开发,如果任何其他分支被合并到主干中,则从主干重新平衡,当我们准备好测试后,我们部署分支。 当测试正常时,我们合并到主干,然后发布到测试版。 在合并之前,我们在主干上做一个版本以避免出现问题。

在beta正常之后,我们发布到prod。

我今天正在开发我们产品的3.0版本,并将我的代码更改签入主干。发布仍在几周前。

一个同事正在试验一些特性,这些特性可能会使它变成4.0,但绝对不会变成3.0。她正在把自己的东西整理成一个独立的部门。把那种东西放进后备箱是不对的。

另一位同事正在修复版本2.5中的错误,我们已经将其发送给了客户。出于明显的原因,他正把他们送进2.5分公司。

所以,要回答标题问题(如果每个人都是从主干发展起来的,我的答案是否定的。

P.S.关于合并。稍后我们可以有选择地将一些东西从2.5分支合并到主干,但不能从主干返回到分支。主干和4.0分支之间的合并可以双向进行。

AS Neil Butterworth said ,这取决于;存在几种有效的方法。

然而,我个人建议拥有一个稳定的主干,并在临时分支上进行所有主要的开发。(即,只有小的、独立的变化 完成 只需一次提交,就可以直接提交到主干。)为了避免长寿命的分支离主线太远,(auto)至少每天将所有进入主干的分支合并到所有开发分支。哦,还有 一切 应该由CI____尤其是在哈德逊,这是一个快速和造成很少的开销。

如果对我们如何应用此功能感兴趣,请参阅 this answer .(我不想重复太多…:)

我实际上会推荐这种方法,即使它只是一个团队在代码库上工作,而且 即使 如果每个人都在使用相同的功能/更改。为什么?嗯,因为根据我的经验(除非在您的环境中,发布时间表、要求等事情是可以预测的),把您的主干放在 可释放形状 ,一直以来。

我有开发人员创建项目分支或更改请求/bug分支,然后合并回主干,所以在某种程度上,我有开发人员在主干之外工作,但是进入“合并”分支的内容是通过一些构建控制工具或过程来控制的。

我认为这是相当好的覆盖 this question

是的,那应该是您发布的工作副本。所有分支都应该是代码的早期版本。

这完全取决于您的发布时间表。如果当前正在定期签入的所有工作都打算立即释放,那么它们都可以签入一个区域,如主干。如果有一些工作将被推迟,而其他的,尚未完成的工作,必须先出去,第一个出去的代码可以提交到主干,下一个代码在它自己的分支,或者反之亦然。

您应该发现,合并和刷新分支在某些情况下有时会出错是一件麻烦的事情。所以自然地,尽量减少这种情况是有意义的。源代码管理的总体思想是每个人都可以在一个地方工作。

通常,当您拥有更大的团队时,发布时间表是由子团队及其项目组织的,并且它们有自己的分支。

对。
把你的最新分支变成你最新的版本是没有意义的。然后,你的树干从树枝上变得过时了。

我认为如果您是敏捷的,并且在几周内以小的增量发布,那么您应该在主干中进行开发。这样,你就有了最新的后备箱,它会不断地被构建,可能会被破坏,但很快就会被修复,当你准备好释放它时,标记它并释放它。这样一来,从分支合并也不会让人头疼。

我想我还想补充一点,如果你是在分支中开发的,你就不可能是敏捷的。在分支中开发只能在瀑布中工作。

我认为你使用的工具也是一个重要因素。

• 如果您使用的是颠覆,不稳定的主干可能会更好地为您工作。
• 如果您使用的是Git,那么稳定的主干比颠覆要容易得多。

在我的公司中,我们采用了稳定的主干开发模型,代码在开发中,并在分支上进行了充分的测试,然后合并到主干上。 但是我发现这个实践相当令人生畏,因为验证团队通常需要几个月的时间来全面测试特性分支。所以我们最终会发现这些树枝在我们能把它们合并回树干之前,会在周围逗留数月。

另一方面,使用不稳定的主干开发,所有的变更都会一直进入主干,但是随后我们的验证团队开始抱怨他们对代码没有信心,因为每个人的变更都在那里,没有隔离。

所以看起来这两种方法都不是最佳的。对于一个需要很长时间才能验证的团队,是否有一种更为理想的方法?