0

为我们的开发工作中出现的情况寻找一些分支策略。我们正在使用 TFS 2010 并使用具有三个分支的基本两个分支分支方案：Dev、Main（这是其他两个分支的稳定主分支）和 Release。目前 Main 和 Release 是相同的，并且在 Dev 分支中正在进行很多更改。

当我们开始最新的开发项目时，假设我们将遵循我们的常规做法，并将在 Dev 分支中完成的所有事情都带到一个点，然后开始发布过程。好吧，像往常一样，事情发生了变化，现在我们希望只完成在 Dev 分支中完成的一些工作（大约 20% 的更改），并希望对其进行发布。

我们希望推广的大多数更改都是独立的，但有一些文件需要检查并仅保留我们关心的发布功能。

那么，考虑到我们当前的两个分支策略，我们如何协调最初应该按照基于多特征的分支策略的方式构建的东西？

这是我们第一个使用 TFS 的大型项目，不幸的是，我们没有通过让变更集包含多个功能的东西，而不是使用标签等来练习良好的源代码管理。

在我看来，最坏的情况是从 Main 创建一个新分支，称为 Feature1，然后必须手动将更改从 Dev 分支复制到 Feature1 分支。这是唯一的方法还是有更有效的方法？

4

1 回答 1

0

是的，我认为您需要创建一个新分支。但我不会称它为 Feature1。我会开始使用 Release 分支。

从 Main 创建一个 Release 分支。然后合并（不手动复制）您计划包含在 Dev 版本中的所有内容。如果主分支没有更改，则合并不应导致任何冲突。现在您可以在 Release 分支中开始稳定工作。

可以在 Dev 中继续工作，当版本准备好时，您可以合并从 Release 到 Dev 的所有修复以及对 Main 的所有更改。

由于您今天不使用标签，我认为您应该锁定 Release 分支。对于下一个版本，您创建一个新的 Release 分支。（确保在开始之前为所有发布分支考虑一个好的命名约定）然后你总是能够回到每个发布。

于 2012-08-03T13:15:52.953 回答