Version control 网站的分支结构

我最近在阅读，它建议每个版本都有一个分支。对于一个网站，一次只发布一个“版本”。在这种情况下，设立一个“生产”分支机构是否合适？然后，在准备发布的过程中，将主分支中的更改合并到生产中。（与每个版本分支的建议相反）如果需要进行热修复，请在生产分支中进行，然后反向集成到主版本中。通过这种方式，您可以在生产分支中保持生产配置文件的完整性

p、 我应该提到的是，我们使用的是代码提升模型

p、 显然，我所说的是存在的：在你的问题是什么？ 这就是我们目前使用TFS的方式（顺便说一句，它是ace）

我不知道它是否“合适”，但我对Subversion做了类似的事情

---

我没有分支/标签/主干，而是开发/测试/生产。在开发中创建了新功能/修复程序。一旦完成，它们将被合并到测试中进行测试和客户审查（通过访问测试网站）。通过QA后，更改将合并到生产中。钩子脚本会在签入时自动更新相应的开发、测试和生产网站，每个“分支”都有自己独特的web.config文件，指向相应的开发/测试/生产数据库。

通常，生产用于反映生产中的内容，即：

• 在现场推送了什么
• 再加上直接在现场制作的热修复程序

这就是为什么在这种配置中，一个生产分支就足够了

然后，您需要遵循该逻辑：

• 发布分支，在将当前版本合并到生产分支之前，在其中整合开发并测试它们。它们可以作为登台环境的源，因为，正如您在问题中引用的文档（实用性能）中所述：
  它允许您进行非常频繁的发布，而不必为每个发布分支新的代码行。（它们通常用于支持web开发）
  暂存流本质上是一个可重用的发布代码行。每个暂存流用于释放稳定的特定阶段

• 日常开发人员的开发分支（所有这些分支不能总是下一版本的一部分），以及集成在Prod中制作的修补程序（将Prod合并到Dev）

---

“拥有一个“生产”分支是否合适？”读过这篇文章后，您认为我们需要多个“发布”/“集成”分支吗？现在我们只有一个。@steve_d:如果你有一个足够“连续”的开发生命周期，你可以重用同一个版本分支，但为了清晰起见，我更喜欢每个版本都有一个。不管怎么说，分支是便宜的，加上合并工作将保持不变。分支是便宜的——成本来了就是合并。@steve_d:因此“合并工作将保持不变”的重要性我的部分评论：从一个唯一的发布分支或从以发布命名的发布分支合并不会改变。从分支合并的努力不会增加，但合并到发布分支的努力至少与分支的数量成线性关系。（将release1的更改从主干/主干合并为release2和release3以及…）