代码之家 › 专栏 › 技术社区 › Gerrie Schenck

如何在分支上合并功能和错误修复

branch tfs

Gerrie Schenck · 技术社区 · 16 年前

简单地说,我有以下分支设置:

MAIN
   |--- DEV
   |--- PROD

大多数开发是在dev分支中完成的。当代码准备好测试时,所有内容都将合并到主分支并发布到我们的测试环境中。测试完成后,将完成与Prod的合并,并将所有内容发布到生产服务器。偶尔对主代码或产品代码进行更改(主要是修正错误),但这是一个例外。

我被要求考虑一个功能和错误修复合并的系统。这意味着dev中的单独更改应该跨main和prod合并。使用当前的设置,这些信息将丢失:例如,特性A、B和C在dev分支中实现。假设每个特性都有两个对应的变更集:a1、a2、b1、b2、c1、c2。按照我们目前的工作方式,所有的东西都一次合并到主分支。因此,当我们想要“挑选”必须从主产品到产品的特性时,我们不能这样做,因为主产品上只有一个变更集:合并的签入。

你将如何解决这个问题?我需要改变我的分支策略吗?

我正在使用TFS进行源代码管理。

2 回复 | 直到 16 年前

Richard Berg 16 年前

因此,当我们想要“挑选”必须从主产品到产品的特性时,我们不能这样做,因为主产品上只有一个变更集:合并的签入。

如果你愿意的话,你可以写一个工具来划分合并历史,但真正的答案是 不要那样做 .当您挑选时,您将失去任何保证,即您在源分支中测试和稳定的代码将在目标分支中以相同的方式执行。有时这没关系,但在您的情况下,它破坏了在原始未测试的开发人员签入和您的实时prod部署之间放置中间分支的整个目的。

正如在 my favorite branch/merge video 您的指导原则应该是“向下合并,向上复制”。也就是说,每当需要解构和/或应用代码差异时,就让不稳定的分支受到攻击。(另一个例子是从一个集成的应用程序中挑选特性。)同时,向稳定分支(如main&prod)提升的代码应该始终是一个直接副本,与您在源分支中为稳定所做的努力相匹配。听起来你目前正在遵循这一策略;在挑选关键人物时保留这一策略将是我使用功能分支的动机,甚至比将功能团队与其他人的崩溃隔离更重要。

正如Jim提到的,管理特性之间的依赖性是一个问题。如果您可以提前识别它们,通常的解决方案是使具有公共依赖关系的特性共享子分支。

Feature1
     \
    LibA---
     /     \
Feature2    \
           DEV -- MAIN -- PROD
Feature3    /
     \     /
    LibB---
     /
Feature4

当然,软件并不总是按计划运行。如果需要共享代码的分支位于树的另一侧(例如,如果Feature1依赖于liba,那么这根本不起作用和但由于结构或技术原因,功能2不适合作为B的一部分)。

Jim T 16 年前

我不认为这里有什么神奇的调料,你只需要找到一个系统,你可以为你想挑选的每一个单元修改主系统。

这可以通过单独合并每个修订来完成,这是一种痛苦,但可以得到你想要的。

或者,您可以通过一次将每个特性合并到主特性中来提高粒度。这要求您按顺序处理功能,如果您是自己的,这可能是可以的,但如果有几个人,这将是一个痛苦的,因为您必须经历一个代码冻结,其中有些人已经完成,而其他人没有。

另一种工作方式是为每个特性建立一个dev分支,这种工作方式可能更易于管理,也可能不易管理。从这个意义上讲,它不是拥有一个永远存在的dev分支,而是拥有一个短暂dev分支的集合,这些分支只存在于功能完成之前。

每个dev分支的重新集成将为您提供一个主要的清晰修订版,您可以从中挑选。

您可以获取开发分支之间的依赖关系。假设分支deva需要分支devb的一些实现,您必须将devb的必需部分合并到main中,然后将它们合并到deva中。然而,deva不应该需要devb未完成的工作,所以您(理论上)无论如何都应该能够愉快地ri那些部分。当然,由于您对Prod非常感兴趣,所以这些部分集成不必发布。

考虑到你的分支策略,我想你已经找到了这个,但是如果没有,它值得一读: http://branchingguidance.codeplex.com/wikipage?title=html&referringTitle=Home