寻找支持集成测试分支的TFS分支方案
我们正在考虑从 SVN 迁移到 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在这个版本中消失，我们会等到下一个版本”。
在某些时候，当某个功能通过了 QA 并且业务部门签署了该功能时，我们会将已接受的功能合并到 Trunk（发布/生产）。
Feature1 --(merge)--> Trunk
Feature3 --(merge)--> Trunk
然后我们基于 Trunk 构建我们的版本（并用版本号标记它）
所以我正在寻找一种在 TFS 中进行类似工作的方法。由于您似乎只能合并到祖先，因此我可以将其设置为：
Trunk
|- Testing
|- Feature1
|- Feature2
|- Feature3
并从功能分支合并到测试。但是，那么我将需要仅将源自Feature1 和Feature3 的修订从Testing 合并到Trunk，而忽略Feature2 的修订。这似乎是一项非常乏味且容易出错的工作，需要手动检查每个更改以查看它来自哪个分支？这就是为什么在我们的 SVN 方案中，我们会将功能分支直接合并回主干。
似乎必须将功能分支重新集成到公共测试分支应该相当常见，但我想我没有看到一种简单的方法来仅获取源自特定叶子的变更集以进行下一步合并。
有人有任何意见吗？我们当然也愿意修改我们的分支计划。我们之前所做的恰好在 SVN 中运行正常。我怀疑这在 git 中也不难，因为您实际上可以将整个功能压缩为单个提交，然后将该提交合并到任何其他分支。
感谢您的任何意见！
其他说明：
我们正在使用 TFS 2010。我之前忘了提及这一点。
另一种选择是在将功能合并到主干之前删除测试分支中某个功能的所有更改。这将是 SVN 中的“反向合并”。我看到有一个 tf.exe /rollback 命令，但看起来它需要一个变更集编号。每个功能可能是多个变更集，所以我仍然没有找到一种方法来找出测试中源自FeatureX合并的变更集列表...
We are considering moving from SVN to TFS, so I am trying to find a proper workflow to follow in TFS to accommodate our needs. There are a lot of branching scheme discussions out there, but most that I have seen have 1 thing in common that doesn't fit our needs; almost all branching schemes assume your branches are testable.
So we create some feature branches from Trunk:
Trunk --(branch)--> Feature1
Trunk --(branch)--> Feature2
Trunk --(branch)--> Feature3
In our case, we are making 'feature' branches, each feature branch can be unit tested, but can not be QA tested. This is because each feature branch would need to have its own DB instance, and a web server, and we plain don't have the resources for that. So we merge our feature branches back to a 'testing' branch. Our QA team then tests all the features (as they are ready) in the testing branch.
Feature1 --(merge)--> Testing
Feature2 --(merge)--> Testing
Feature3 --(merge)--> Testing
Now this is where things get strange...
Note that the feature branches are not really int he same hierarchy as 'testing' branch. In SVN I guess you would call this a 'baseless' merge, which I don't think TFS supports...
In QA testing, a particular feature can fail testing, or more commonly the business will decide "nevermind, we don't want Feature2 to go out this release, we'll wait until next release".
At some point, when a feature has passed QA and the business signs off on it, we merge our accepted features to Trunk (release/production).
Feature1 --(merge)--> Trunk
Feature3 --(merge)--> Trunk
Then we build our release off of Trunk (and tag it with a version number)
So what I am looking for is a way to make something similar work in TFS. Since you seem to only be able to merge to an ancestor, I could possibly set this up like:
Trunk
|- Testing
|- Feature1
|- Feature2
|- Feature3
And merge from the feature branches to Testing. However, then I would need to only merge the revisions that originated from Feature1 and Feature3 from Testing to Trunk, ignoring Feature2's revisions. This seems like it would be a terribly tedious error-prone job of hand-inspecting each change to see what branch it came from? This is why in our SVN scheme, we would have merged our feature branch directly back to trunk.
It seems like having feature branches that have to be re-integrated to a common testing branch should be fairly common, but I guess I'm not seeing an easy way to only get the changesets that originated in a particular leaf for the next step of the merge.
Anyone have any input? We are certainly open to revising our branching scheme too. What we did before just happen to work OK in SVN. I suspect it wouldn't be hard in git either, since you could actually squash an entire feature into a single commit, and just merge that commit to any other branch.
Thanks for any input!
Other notes:
We are using TFS 2010. I forgot to mention that earlier.
Another option would be removing all the changes from a feature from the Testing branch, before merging it to Trunk. This would be a 'reverse merge' in SVN. I've seen that there is a tf.exe /rollback command, but it looks like it takes a changeset number. Each feature might be multiple changesets, so I still don't see a way to figure out the list of changesets in Testing that originated from a merge from FeatureX...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
TFS 支持无基础合并，它们只需通过命令行进行。请参阅 此处了解其工作原理的介绍。一旦你完成了无基础的合并，分支之间就会建立一个额外的“链接”。从那时起，您将能够从 GUI 进行合并。
因此，您提出的结构可以工作：
前提是您已经完成了三个无根据的合并（Feature1 -> Trunk）、（Feature2 -> Trunk）和（Feature2 -> Trunk）。 (功能3->主干)。
另一种类似但可能更好一点的方法如下：
然后通过无基础合并手动建立（功能 1 -> 测试）& （功能2->测试）。
这样，您就可以使用
Testing作为转储区域，一旦Testing中的 FeatureX 一切正常（测试正常，mgmnt 决定使用它）您就可以将它推到您的行李箱中。一般来说，ALM rangers TFS 分支指南并不将无根据的合并视为“最佳实践”。看看你的工作流程，恐怕我找不到 ATM 作为你不使用它的替代品。
Baseless merges are supported in TFS, they are just to be made via command line. See here for an intro on how it works. Once you 've done a baseless merge, an additional 'link' between the branches is established & from then you 'll be able to merge from the GUI.
So your proposed structure could work:
provided you have done three baseless merges (Feature1 -> Trunk), (Feature2 -> Trunk) & (Feature3 -> Trunk).
Another similar -yet possibly a bit better- approach can be the following:
and then -by hand- establishing via baseless merges (Feature1 -> Testing) & (Feature2 -> Testing).
This way you 'll be able to use
Testingas a dump-zone, and once everything checks out ok for FeatureX inTesting(tests ok, mgmnt decides to use it) you 'll be able to push it to your trunk.In general, baseless merging is not considered 'best practices' by the ALM rangers guide on TFS branching. Looking at you workflow, I 'm afraid I can't find ATM an alternative for you that doesn't use it.
两者肯定都需要权衡，在我看来，这归结为你的功能团队之间有多少重叠。正如 pantelif 所指出的，您确实也可以在 TFS 中进行无基础合并，但它不如分支之间具有适当的合并关系那么迷人，并且在进行无基础合并时会失去很多合并功能。
我认为确定要合并到第二个插图中的变更集：
没有您想象的那么乏味。考虑一下，当您将功能 1 中的多个变更集（例如 1、2 和 3）合并到测试中时，此合并将作为测试分支中的单个变更集提交（例如变更集 4）。当您签署了功能工作后，您只需与选定的变更集合并并选择变更集 4 即可合并到主干。（也就是说，您不必重新选择所有原始变更集 1、2 和 3） .) 当然，您必须做一些工作来确定哪个合并变更集包含该功能工作，但我假设您没有如此频繁地合并到主干中，以至于很难识别。 （如果这是一个错误的假设，请忽略我。）
但是这种结构的大问题是功能 1 工作和功能 2 工作之间需要合并。假设他们都对相同的类进行更改。现在，如果您只想将其中一个功能分支升级到主干，那么您必须取消合并这些更改，直到其他功能的工作准备好升级为止。这听起来确实乏味且容易出错。
如果这是一个完全边缘的情况，并且您的功能分支主要独立工作，几乎没有重叠和琐碎的合并，我会选择这种结构。但是，如果这是一种常见情况，那么我可能会采用毫无根据的合并路线。
There are definitely tradeoffs to both and, in my opinion, it boils down to how much overlap your feature crews have with each other. As pantelif noted, you can indeed do baseless merges in TFS too, but it's less glamorous than when you have a proper merge relationship between branches and you lose a lot of the merging capabilities when you do a baseless merge.
I think identifying the changesets to merge in your second illustration:
is less tedious than you think. Consider that when you merge several changesets (say 1, 2 and 3) from Feature 1 into Testing, this merge will get committed as a single changeset in the Testing branch (say changeset 4). When you've signed off on the feature work, you can merge up to Trunk just by merging with Selected Changesets and choosing changeset 4. (That is to say that you don't have to reselect all those original changesets 1, 2 and 3.) You will, of course, have to do a little work to determine which merge changeset contains that feature work, but I'm assuming that you're not merging into trunk so frequently that it would be hard to identify. (And if this is a bad assumption, then ignore me.)
But the big problem with this structure is when there's merging required between Feature 1 work and Feature 2 work. Let's say they both make changes to the same classes. Now if you only want to promote one of the feature branches up to Trunk then you'll have to unmerge those changes until the other feature's work is ready to be promoted. And that does sound tedious and error prone.
If this is a total edge case and your feature branches work mostly independently with little overlap and trivial merges, I'd choose this structure. If, however, this is a common scenario, then I'd probably go with the baseless merge route.
所以我认为正如上面提到的，从命令行进行毫无根据的合并会帮助你。其次，您提到了大约 80 次提交。在我们的项目中，我们在 TFS 中创建任务。根据流程，每个开发人员只有首先将其签入与任务“关联”，才能提交。因此，如果我有一个修复 x，我会为其创建一个任务，然后即使有 80 个提交，所有提交都链接到该任务，这使我可以在将来随时轻松查看分组。
So I think as people mentioned rightly above, baseless merge from command line would help you out. Secondly, you mentioned about 80 commits. In our project we create tasks in TFS. As per process, each developer is able to commit only if he first "associates" his check-in against a task. So If i have a fix x, I create a task for the same, and then even if there are 80 commits, all of them are linked to this task, which allows me to easily view the grouping anytime in future.