寻找支持集成测试分支的TFS分支机制

我们正在考虑将SVN从TFS迁移到TFS，因此我正试图在TFS中找到适合我们需求的正确工作流程。在那里有很多分支机制的讨论，但我见过的大多数有一个共同点，不符合我们的需求;几乎所有的分支机制都假设你的分支是可测试的。寻找支持集成测试分支的TFS分支机制

所以我们从主干创建一些特性分支：

Trunk --(branch)--> Feature1 
Trunk --(branch)--> Feature2 
Trunk --(branch)--> Feature3

在我们的例子中，我们正在“功能”分支，每个分支的特征可以进行单元测试，但能不能是 QA测试。这是因为每个功能分支需要拥有自己的数据库实例和一个Web服务器，而我们显然没有这方面的资源。所以我们将我们的功能分支合并回“测试”分支。我们的QA团队随后在测试分支中测试全部功能（因为它们已准备就绪）。

Feature1 --(merge)--> Testing 
Feature2 --(merge)--> Testing 
Feature3 --(merge)--> Testing

现在，这是事情变得陌生...... 注意，特性分支没有真正诠释，他的同一层“测试”分支。在SVN我猜你会称这是一个“毫无根据”合并，其不认为我TFS支持...

在QA测试，一个特定的功能可能会失败的测试，或更普遍的业务将决定“从来没有想过，我们不希望Feature2发布此版本，我们将等到下一个版本发布。“

某些时候，如果某个功能已通过质量保证并且业务已经通过验证，我们会将我们接受的功能与Trunk（发布/制作）合并。

Feature1 --(merge)--> Trunk 
Feature3 --(merge)--> Trunk

然后我们建立我们释放掉干线（以及其版本号标记的话）

所以，我在找的是一种方法，使在TFS一些类似的工作。既然你似乎只能够合并的祖先，我可能设置此类似：

Trunk 
|- Testing 
    |- Feature1 
    |- Feature2 
    |- Feature3

而且从功能分支合并测试。但是，那么我需要只有合并来自Feature1和Feature3的测试版本到Trunk，忽略Feature2的修订版本。这似乎是手工检查每个变化以查看它来自哪个分支的一项非常单调乏味的容易出错的工作。这就是为什么在我们的SVN方案中，我们会将我们的功能分支直接合并到主干。

好像有功能分支必须重新集成到一个通用的测试分支应该是相当普遍的，但我想我没有看到一个简单的方法来获取源自特定叶的变更集合并的下一步。

任何人有任何输入？我们当然也愿意修改我们的分支机制。我们之前完成的工作恰好在SVN中正常工作。我怀疑它在git中也不会很难，因为你实际上可以将整个功能压缩到单个提交中，并且只是将该提交合并到任何其他分支。

感谢您的任何意见！

其他说明：

我们使用TFS 2010年我忘了提早。

另一个选项是将中的所有更改从测试分支中的功能中移除，然后再将其合并到Trunk。这将是SVN中的“反向合并”。我看到有一个tf.exe /rollback命令，但它看起来像需要一个更改集编号。每个功能可能是多个变更集，所以我仍然没有看到一种方法来找出源自FeatureX合并的测试中的变更集列表...

来源

2011-10-06 CodingWithSpike

请参阅[Visual Studio团队基础服务器分支指南2010]（http://tfsbranchingguideiii.codeplex.com/） –

TFS支持无基本合并，它们只是为了通过命令行进行。关于它的工作原理，请参阅here。一旦你做了一个毫无根据的合并，在分支之间建立一个额外的'链接'&从那时你就可以从GUI进行合并。

所以你提出的结构可以工作：

Trunk 
|- Testing 
    |- Feature1 
    |- Feature2 
    |- Feature3

只要你有做了三个毫无根据的合并（特征1 - >干线），（特征2 - >干线）&（特征3 - >干线）。

另一个类似的 - 可是可能有点更好 - 方法可以是以下：

Trunk 
|- Feature1 
|- Feature2 
|- Feature3 
    |- Testing

然后-by手工通过无端合并建立（特征1 - >测试）&（特征2 - >测试）。
通过这种方式，您可以使用Testing作为转储区域，并且一旦所有内容在Testing（测试成功，mgmnt决定使用它）中检查出FeatureX，您就可以将其推送到您的主干。

通常，TFS分支上的ALM游侠guide未将无基本合并视为“最佳实践”。看着你的工作流程，恐怕我找不到自动取款机替代你，不使用它。

来源

2011-10-06 14:35:12 pantelif

感谢您的想法。实际上，我们目前的SVN方案与您的第二种方法相似，在这种方法中，我们从功能到测试都没有根据地合并。然后我们定期扔掉测试分支。我只是没有意识到你可以毫无根据的合并从他的CMD线。 – CodingWithSpike

这两者之间肯定存在权衡，在我看来，这归结为您的功能团队与对方之间的重叠程度。正如pantelif指出的那样，您确实可以在TFS中进行无基础的合并，但与分支机构之间具有适当合并关系时相比，它更没有魅力，当您进行无根据合并时，您失去了很多合并功能。

我觉得标识的变更在你的第二个例证合并：

Trunk 
    |- Testing 
     |- Feature1 
     |- Feature2 
     |- Feature3

比你想象的那么乏味。考虑到将特征1中的多个变更集（比如1,2和3）合并到测试中时，此合并将作为测试分支中的单个变更集提交（例如变更集4）。当您签署特征工作时，只需合并选定的变更集并选择变更集4即可合并到Trunk。（也就是说，您不必重新选择所有原始变更集1,2和3 ）。当然，您将需要做一些工作来确定哪些合并变更集包含该功能，但我假设您没有频繁地合并到主干中以至于难以识别。（如果这是一个糟糕的假设，那就不要理我了。）

但是这个结构的一个大问题是当Feature 1工作和Feature 2工作之间需要合并时。假设他们都对相同的类进行了更改。现在，如果您只想将某个功能分支提升至Trunk，则必须先取消这些更改，直到其他功能的工作已准备好提升为止。这确实听起来乏味且容易出错。

如果这是一个总的边缘情况下，你的功能分支主要独立工作，几乎没有重叠和微不足道的合并，我会选择这种结构。但是，如果这是一种常见的情况，那么我可能会采用毫无根据的合并路线。

来源

2011-10-06 16:17:41

感谢您的输入Edward。在“合并”成为1变更集; SVN和TFS发生的问题;如果我在合并的分支中有待处理的更改，然后从特性中抽取更改2 + 3 + 4，并将其作为更改集5提交，现在我可能无意中也提交了来自我合并分支的未决更改。 – CodingWithSpike

（由于字符太多而引起的第二条评论）......有时候，某个功能会被合并为多次测试，错误修复或其他更改，并且由于每个合并的更改集都会收到自己的提交消息，因此需要开发人员做出一个很好的提交消息，说“这是从Feature1合并”或其他。但是，你知道它是怎么回事......你会得到80个提交文本“错误修正”或“合并”的提交:)这已经是我们在SVN中处理的东西，但希望我们可以在TFS中更好地处理它。 – CodingWithSpike

是的，我理解第一个痛点 - 我在一个单独的TFS工作区中进行合并，这样我就没有任何意外集成未决更改的机会。当然，这需要2倍的磁盘空间，这可能是巨大的项目压倒性的。而且你的错误修复问题当然是一个很好的观点。因为我喜欢有分支可视化和拖拽拖拽位的闪亮UI，所以我偏向于无根据的合并，但它可能是正确的方式。 –

所以我认为，正如人们在上面提到的那样，从命令行毫无根据的合并会帮助你。其次，你提到了大约80次提交。在我们的项目中，我们在TFS中创建任务。按照流程，每个开发人员只有在首次将其签入与检查任务“关联”时才能提交。因此，如果我有一个修复x，我创建一个相同的任务，然后即使有80个提交，他们都链接到此任务，这使我可以随时轻松查看分组。

来源

2011-10-08 15:50:46

寻找支持集成测试分支的TFS分支机制

回答

相关问题