Team Foundation：多重发布结构
我需要帮助设置 TFS 分支结构。
目前的场景如下，我们的应用程序是一个SaaS，我相信我们需要同时多个“Release”分支。
通过阅读《TFS 分支指南 III》，我相当确定我们需要“高级”分支模型。
我们从一个“主”分支开始，它将容纳现在的应用程序（我们来自 Visual Source Safe）。从此我们将创建一个“开发”分支，并暂时保留它。我们还将创建一个新的“Service Pack”、“Hotfix”和“Release A”分支树，其中将包含我们当前的更改集。然后，我们将让我们的 QA 团队分析“Release A”分支，如果它通过，我们将关闭它（只读），并将其合并回“main”。
到目前为止一切都很好。
出现的问题是，QA 周期大约需要一个月，因此与此同时，我们希望我们的开发人员能够为“Release B”开发新的“Service Pack”和“Development”项目，该项目也将拥有自己的“Service” Pack”、“Hotfix”和“Release B”分支。
这意味着我们一次有 2 个发布分支（当然除非有更聪明的方法）。
问题： 如果“版本 B”是在“开发”项目完成之前创建的，则需要“版本 A”的“修补程序”，我如何将该“修补程序”从“版本 A”传播到“版本 B”而不选择同时完成的任何“开发”项目吗？
I am in need of help setting up a TFS branching structure.
The current scenario is as follows, our application is a SaaS, and I believe we need multiple "Release" branches simultaneously.
Going through the TFS Branching Guide III, I'm fairly certain that we will need the "Advanced" branching model.
We start with having a "main" branch, which will house the application as it stands right now (we're coming from Visual Source Safe). From that we will create a "Development" branch, and leave that alone for now. We will also create a new "Service Pack", "Hotfix", and "Release A" branch tree which will contain our current set of changes. We will then have our QA team analyze the "Release A" branch, and if it passes we will then close it (read only), and merge it back to "main".
That's all fine and dandy so far.
The problem arises, is that the QA cycle takes approximately a month, so in the meantime, we want our developers to work on new "Service Pack" and "Development" projects for "Release B", which will also have its own "Service Pack", "Hotfix", and "Release B" branches.
This means that we have 2 release branches going at a time (unless of course there's a smarter way of doing it).
Question:
If "Release B" is created BEFORE a "Development" project is completed, then a "Hotfix" for "Release A" is required, how do I propagate that "Hotfix" from "Release A" into "Release B" without picking up any "Development" projects that get completed in the meantime?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
简短回答：对于所描述的具体场景，我相信您可以安全地从版本 A 合并到主版本，然后备份到版本 B。（是的，这与 Geoffrey McGrath 在 8 的评论中所说的相同/16.) 通常，在创建分支后，您不会从 Main 到发布分支进行任何 FI 合并，但如果您可以确认 Main 中存在的唯一更改是您的修补程序，那么合并应该可以安全地实现您的目标。 但是这是基于一个非常可疑的假设，即自“Release B Servicing”分支以来，您有一个干净的 Main 分支，没有其他任何内容合并到 Main 中。在继续之前请仔细验证这个假设！
肮脏的 Main 解决方法 - 挑选或无基础合并：如果 Main 中有其他更改，您可以挑选将特定修补程序从 Main 合并到“Release B Service Pack”。另一种选择是从“Release A Servicing”直接进行无基础合并到“Release B Servicing”，从而绕过 Main 中的任何其他更改。 （您仍然需要通过 main 合并此修复程序，以便 Dev 分支获得修补程序。）请注意，cherry-pick 合并和无基础合并比常规合并具有更高的风险（这可能很棘手）。对于不存在更好解决方案的特定场景，它们仍然是有效的选择。
Meta-answer#1：我发现绘制图表可以帮助我跟踪从原始分支到最终目的地的变化。 Cherry-pick 没有任何特殊的符号，但无根据的合并可以是带有虚线的箭头。如果它在纸上有效（并且您考虑了与主分支的所有其他分支交互），那么它应该有效。
Meta-answer#2：如果以上没有完全回答您的问题，那么我建议您阅读http://tfsbranchingguideiii.codeplex.com/discussions 论坛并交叉发布此特定请求。 Bill Hays 在该论坛中的反应通常非常积极，您的问题肯定指向 TFS 分支内的修补程序管理。
仅供参考：
我的团队从事一些 SOA（面向服务的架构）项目，这些项目遇到了与 SaaS 类似的挑战。一个月的质量检查周期是一个棘手的复杂问题。
我非常喜欢马丁的文章（足以在下面再次引用它）。还有另外两篇文章值得回顾（两篇文章都有漂亮的图片来补充漂亮的 TFS 分支指南图）。然而，所有三篇文章都重点关注开发分支管理而不是修补程序发布分支管理（与之前答案中的图表相同）。
享受！ -Zephan
Short Answer: For the specific scenario described I believe you could safely merge From Release A through Main and then back up to Release B. (Yes, this is identical to what Geoffrey McGrath stated in a comment on 8/16.) Typically you don't do any FI merges from Main to a release branch after creating the branch, but if you can confirm the only change present in Main is your hotfix then the merge should safely accomplish your goal. HOWEVER this is based on the very questionable assumption that you have a clean Main branch with nothing else has merged into Main since "Release B Servicing" was branched. Verify this assumption very carefully before proceeding!
Dirty Main workarounds - cherry picking or baseless merge: If there are other changes in Main they you can cherry-pick merge the specific hotfix from Main to "Release B Service Pack". Another option is to do a baseless merge from "Release A Servicing" directly into "Release B Servicing" which bypasses any other changes in Main. (You still need to merge this fix through main so Dev branches get the hotfix.) Note that cherry-pick merges and baseless merges have higher risk than regular merges (which can be tricky enough as-is). Still they are valid options for specific scenarios where no better solution exists.
Meta-answer#1: I find drawing a diagram helps me follow the changes from original branch to the final destination. Cherry-pick doesn't have any special notation, but baseless merge can be arrow with dotted line. If it works on paper (and you accounted for all other branch interactions with Main) then it should work.
Meta-answer#2: If above hasn't outright answered your question then I'd recommend reading the http://tfsbranchingguideiii.codeplex.com/discussions forum and cross-post this specific request. Bill Hays is typically very responsive in that forum and your question definitely points to hotfix management within TFS branching.
FYI:
My team works on a few SOA (Service Oriented Architecture) projects which encounters similar challenges to SaaS. The one month QA cycle is a tough complication.
I like Martin's article a lot (enough to cite it again below). There are two additional articles worth reviewing (both have pretty pictures to augment nice TFS Branching Guide diagrams). However all three articles focus on dev branch management rather than hotfix release branch management (same as diagram in the earlier answer).
Enjoy! -Zephan
查看来自 http://blog 的图表。 Hinshelwood.com/guidance-a-branching-strategy-for-scrum-teams/ 并阅读整个博客条目：
您的“开发”项目在图中称为“Sprint 1”和“Sprint 2”...请注意 Sprint 是如何与 Release 隔离的——除非通过合并，否则您无法访问它们。
Take a look at the graphic from http://blog.hinshelwood.com/guidance-a-branching-strategy-for-scrum-teams/ And also read the entire blog entry:
Your "Development" projects are called "Sprint 1" and "Sprint 2" in the graphic...notice how the Sprints are isolated from Release--you can't get to them except via merge.