网站的分支结构
我最近阅读了 TFS 分支指南，它为每个版本建议了一个分支。对于一个网站来说，一次只能发布一个“版本”。在这种情况下，拥有一个“生产”分支是否合适？然后，在准备发布的过程中，您将主分支中的更改合并到生产中。 （与对每个版本进行分支的建议相反。）如果您需要进行修补程序，请在 Production 分支中进行，然后反向集成到 Main 中。这样做可以让您在 Production 分支中保持 Production 的配置文件完整。
ps 我应该提一下，我们正在使用代码促销模型。
pps 显然我所说的存在：它在 Practical Perforce 中被称为“分段流”
I was recently reading the TFS Branching Guide and it suggests a branch for every release. For a web site, there is only one "version" released at a time. In that case is it appropriate to have a single "Production" branch? Then, during the process of preparing for a release, you merge changes from the Main branch into Production. (As opposed to the suggestion to branch each release.) If you need to do a hotfix, do it in the Production branch, then reverse integrate into Main. Doing it this way allows you to keep configuration files for Production intact in the Production branch.
p.s. I should mention that we are using a Code Promotion model.
p.p.s. Apparently what I'm talking about exists: it's called a "staging stream" in Practical Perforce
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
通常，生产用于反映生产中的内容，即：
这就是为什么在此配置中，一个生产分支就够了。
然后，您将需要遵循该逻辑：
发布分支，您可以在其中整合您的开发并在将当前版本合并到生产分支之前对其进行测试。它们可以作为临时环境的来源，因为正如您在问题中引用的文档（实用Perfoce）中提到的：
<块引用>
它允许您非常频繁地发布版本，而无需为每个版本分支一个新的代码线。 （它们通常用于支持 Web 开发）
暂存流本质上是可重用的发布代码线。每个分段流用于特定的发布稳定阶段。
日常开发人员的开发分支（所有这些都不能总是成为下一个版本的一部分），以及用于集成产品中所做的修补程序（将产品合并到开发人员）。
Usually, Production is for reflecting what is in production, that is:
That is why, in this configuration, one Production branch is enough.
You will then need, following that logic:
release branches where you consolidate your developments and test them before merging the current release to the Production branch. They can serve as source for a staging environment, since, as mentioned in the document you reference in your question (Practical Perfoce):
development branches for daily devs (all of which cannot always be part of the next release), and for integrating back the hotfixes made in Prod (merge Prod to Dev).
我不知道它是否“合适”，但我用 Subversion 做了类似的事情...
而不是分支/标签/主干，我有开发/测试/生产。新功能/修复是在开发中创建的。完成后，它们将被合并以进行测试和客户审查（通过访问测试网站）。一旦通过质量检查，更改就会合并到生产中。 Hook 脚本会在签入时自动更新相应的开发、测试和生产网站，并且每个“分支”都有自己唯一的 web.config 文件，指向相应的开发/测试/生产数据库。
I don't know if it's "appropriate" but I do something similar with Subversion...
Instead of branches/tags/trunk, I have development/test/production. New features/fixes are created in development. Once completed, they are merged to test for testing and client review (by going to the test website). Once passed QA the changes are merged to production. Hook scripts automatically update corresponding development, test, and production websites on checkin, and each "branch" has its own unique web.config file pointing to the appropriate development/test/production database.
你的问题是什么？
这就是我们目前使用 TFS 的方式（顺便说一句，这是 ace）
What is your question?
This is currently how we use TFS (which btw is ace)