分支时是否有使用 EF 4.3 迁移的干净方法？

Question

我正在阅读 EF Migrations 并开始使用它。

我使用 Git 进行源代码控制，每次开始开发新功能时，我都会创建一个分支。这样做的原因是，如果我需要快速跳转到不同的功能，或者进行需要推出的重要错误修复，我可以更改分支并继续工作。

目前我已经设置了我的应用程序，因此如果我不在生产环境中（web.config appsetting），它会破坏数据库并在数据模型发生更改时重新设置它（代码优先）。我认为迁移会很好，因为我不必在最轻微的模型更改上完全删除我的数据。

不幸的是，我看到一些迹象表明它不像我希望的那样对版本控制友好。例如，如果我向我的数据模型添加一个新列，更新数据库，然后决定恢复我的更改，EF 仍然知道模型更改，因为它将它们存储在数据库本身中。

似乎没有干净的方法告诉它在分支第一次发生时降级数据库版本，然后迁移到我决定在没有大量记忆和手动的情况下工作的分支上的数据库位置跟踪。

是否有人制定了如何在具有版本控制的重要开发场景中利用迁移的策略？

Answer 1

因为每个分支都将包含其他明显不知道的迁移，所以它无法知道如何转换数据库以匹配（不使用自动迁移，我怀疑无论如何它会很好用）。

支持不同分支的最佳策略是每个分支都针对自己的数据库副本，具体取决于我们谈论的分支数量。这样您就可以随意在它们之间随意切换，并且它们只会在进行/合并更改时触及自己的数据库。

或者，确保您的核心数据是迁移脚本的一部分，并像现在一样将数据库炸毁。

编辑：合并分支之间的更改后，您可能需要使用 add-migration 命令重新生成它们的元数据。