sql-server - 源代码控制分支策略

Question

我们正在尝试确定在工作中使用的最佳源代码控制分支策略。我们使用连接到 GIT 后端的 VSO 前端。我们有 4 个数据库环境，DEV、QA、STAGE 和 PROD。在任何给定时间，我们都有许多团队致力于不同的功能，这些功能经常相互超越，此外还有大量正在进行的数据库清理工作(添加主键和外键、将列设置为不可空等)

我的想法是维护四个持久分支，每个数据库环境一个，反射(reflect)各自的数据库环境。任何致力于新功能的团队都将从 Dev 分支出来，并且在工作完成时合并回持久的 DEV 分支。当工作准备好进入 QA 时，它将被合并到 QA，当它准备好进入 STAGE 时，它将被合并到 STAGE，依此类推。任何与功能无关的非破坏性数据库更新(例如使列非 NULLABLE)都可以作为更改集流动而无需功能分支，但每个潜在的破坏性更改都需要作为功能分支工作。

有人用过这个策略吗？有用吗？有更好的分支模型可以推荐吗？

Answer 1

好吧，既然最后没有人回答，我将使用我自己的答案进行更新。看起来我们最终将使用这种分支策略，或多或少与我最初描述的一样。主要区别在于 PROD 分支将被称为 master，而功能分支将从 master 而不是 DEV 分支。

这是因为 master/PROD 分支被认为比 DEV 更稳定。我从 DEV 成功分支的先前环境是单个发布序列。由于功能预计会在这里相互跳跃，我们不能那样做。

此外，所有开发都需要在功能分支中完成。然而，这是由于 VSO GIT 插件的限制，因为将 GIT 推送链接到 VSO 票证的机制要求在功能分支中完成工作。