如何在不污染基线的情况下以使测试成为可能的方式分支我的代码？答案

【问题标题】：How can I branch my code in a way that makes testing possible without contaminating the baseline?如何在不污染基线的情况下以使测试成为可能的方式分支我的代码？
【发布时间】：2011-03-22 18:12:25
【问题描述】：

使用 TFS，我们有以下内容：

主要基线
每个开发工作的开发分支。这些将合并回基线。
随每个版本创建的版本分支。错误修复在此处进行、发布并合并回基线。
使用搁置集，我们可以在需要时跨开发分支共享代码，而不会污染基线。对代码审查很有用。
当我们将开发更改交付到基线时，我们有一个自动构建，它会启动并自动将我们的更改放置在测试服务器上。

问题是业务分析师在测试服务器上之前无法看到我们的更改，目前在测试服务器上获取我们的更改的唯一方法是将它们检查到基线中。因此，如果 BA 发现有问题，不幸的是，代码已经处于基线状态，我们将不得不费力将其取出。

有没有一种方法可以改变我们的分支策略或流程，让 BA 得到他们想要看到的东西，而不会污染我们的基线？

【问题讨论】：

标签： tfs branching-and-merging branching-strategy

【解决方案1】：

您的分支战略听起来正是我们在我公司所决定的。我认为问题不在于您的分支策略，我认为问题在于您必须检查基线的更改才能将它们应用到测试服务器。

在我的公司，更改在被推广并在生产中运行之前不会检查到基线中。发布分支是部署到测试服务器的内容...如果发现错误，或者 BA 想要更改某些内容，我们不必经历从基线中删除更改的痛苦。

但是，如果您有很多并发版本，那么在将所有版本移动到生产之前将它们合并在一起可能会很麻烦，因为您要到流程的后期才会合并到基线中。在我的公司，我们有一个非常严格的发布时间表，并且尝试一次只发布一个版本来投入生产。正因为如此，等待将版本合并到基线直到版本被提升到生产中并没有给我们带来任何问题，或者到目前为止的额外工作......

您多久发布一次？您能否将发布分支部署到您的测试服务器上，并让基线代表当前在生产中部署的内容？

（我会对此发表评论，但我仍在努力获得该特权...）

【讨论】：

@mfredrickson 这对于评论框来说会有点长，我认为无论如何这是一个合理的答案。
我们使用 SCRUM 并在每个 sprint 结束时发布，通常需要 3-4 周。所以你为下一个版本创建一个发布分支，然后创建开发分支，然后将开发分支合并回发布并在发布后将发布合并到基线？
哦，如果您还不能发表评论，只需编辑您的答案并将您的跟进添加到底部。
@adam0101 我们就是这样做的……但目前这对我们来说是一个不断发展的过程。现在，对我们来说最难看的部分是在前一个版本投入生产之前开始另一个版本。在这种情况下，我们要么通过分支待定版本来启动新版本，要么分支出基线，然后将提升的版本合并到新版本中，同时将其合并到基线中。对我们来说，这取决于版本的大小……如果有大量更改，我们会从即将发布的版本中分支出来，以避免以后进行大规模合并。
所以使用这种策略，我必须合并并检查我的更改到发布分支，这将启动将更改放在测试服务器上的自动构建。如果 BA 不批准我的更改会怎样？现在我将我的更改与应该在发布分支中发布的更改混合在一起。我仍在努力看看其他人如何处理这个问题。

【解决方案2】：

我不喜欢这种方法，我建议：

包含稳定代码的主要基线。只有在成功发布后，代码才会从相应的发布分支合并到这个分支中。

从 Main 为每个版本创建的 Release 分支。该分支将用于生成 Release Builds 并将部署到测试环境。

从发布分支创建的开发分支，它将用于开发工作，并在我准备好测试构建时合并到发布。

【讨论】：

如果您的更改没有通过测试，您如何处理您的损坏更改与发布分支中其他人的更改混合？您是否以某种方式回滚更改？
如果更改未通过测试，如果需要修复，则在开发分支中修复并将它们合并到发布。如果我们根本不需要这些更改，那么它将使用标签或 tf rollback 命令回滚。
如果其他开发人员在您之后提交了对文件的更改并且您的更改必须回滚，您是否必须以某种方式“取消合并”文件以取出您的更改然后“重新合并”另一个开发商的改变回来了？您将如何处理？
开发人员不会在发布分支中进行任何签入、签出，代码升级由 Dev Lead 进行。在开发中，如果上述场景的更改已回滚，则开发人员将文件的特定版本获取到他想要回滚的版本并进行签入。