我在git下有一个ASP.NET项目，我们遵循为功能使用分支的约定。我们刚刚开始使用SQL Server数据工具来管理架构更改（对它来说很新，所以我怀疑它可能具有让我能够达到我需要的功能）。
我正在寻找一些适用于其他团队的策略，这些团队管理具有不同数据库模式的分支之间的切换，然后成功地将分支合并在一起。理想情况下，在合并所有功能之后，我会隐式创建一个更新脚本，以便部署以便将版本发布到生产环境。
注意我正在使用SQL Server 2008 R2
答案 0 :(得分：0)
此策略有多个部分。一个方面是处理不同分支的存储，对我的团队来说效果很好的是为每个分支使用不同的SQL Server实例（而不是使用分支特定的前缀命名单个数据库）或后缀，例如，MyDatabase_FeatureBranchX，它可能会失控）。这使得每个分支中的相应数据库具有相同的名称（为了清楚起见），但也允许对给定分支的SQL资源（数据文件，访问权限等）进行物理和逻辑隔离。
至于第二个更有趣的方面（我认为是你问题的主要意图），你可以考虑使用基于代码的“迁移”方法 - 例如，使用FluentMigrator等。如果您拥有最初创建每个分支的标准基线模式，则可以在代码中创建适当的迁移，作为每个分支中功能开发的一部分（并将它们应用于该分支的SQL实例）。当将分支合并到主干时，您还要合并然后应用该分支的迁移。
充其量，这意味着您可以在合并后针对主干实例运行迁移工具，以便应用所有分支的迁移，因为这样的工具会自动跟踪已应用的迁移（通过自定义数据库表）并且不要重新应用它们。如果您在整个开发过程中定期将主干代码（包括其迁移）合并到功能分支中，并且您正在应用这些迁移，那么您还需要确保功能分支的模式保持最新，它最大限度地减少了合并时令人讨厌的惊喜。
当需要将主干部署到生产环境时，将再次应用这些相同的迁移。 FluentMigrator提供各种runners：控制台应用程序，NAnt，MSBuild和Rake。
我强烈建议使用基于时间戳（例如，201210241033）的迁移ID策略，而不是简单的顺序整数（1,2，...），以最大程度地减少冲突和更改的可能性序列