我们正在尝试确定在工作中使用的最佳源代码控制分支策略。我们使用附加到GIT后端的VSO前端。我们有4个数据库环境，DEV，QA，STAGE和PROD。在任何特定时间，我们都有许多团队在处理不同的功能，这些功能经常互相跳跃，除了大量正在进行的数据库清理工作（添加主键和外键，将列设置为不可空等）
我的想法是维护四个持久分支，每个分支对应一个数据库环境，反映各自的数据库环境。任何处理新功能的团队都将从Dev进行分支，并且在完成工作时将合并回到持久性DEV分支。当工作准备进入QA时，它将被合并到QA，在它准备好转移到STAGE的时候它将被合并到STAGE等等。任何不受风险限制的非破坏性数据库更新（如使列非NULLABLE）都可以作为更改集流而不需要功能分支，但每个可能发生的重大更改都需要作为功能分支。
有没有人使用过这种策略？它有用吗？ 您可以推荐更好的分支模型吗？
答案 0 :(得分：0)
好吧，因为没有人最后回答我会用我自己的答案进行更新。似乎我们最终会使用这种分支策略，或多或少像我最初描述的那样。主要区别在于PROD分支将被称为master，而功能分支将从master而不是DEV分支。
这是因为主/ PROD分支被认为比DEV更稳定。我从DEV成功分支的先前环境是单一的释放列车。由于预计功能会在这里相互跳跃，我们无法做到这一点。
此外，所有开发都需要在功能分支中完成。这是由于VSO GIT插件的限制，但由于将GIT推送到VSO票据的机制要求在功能分支中完成工作。