使用Entity FrameWork 6.1.3。和Code First。
我目前在自己的分支机构工作，但使用的是开发数据库。另一位开发人员一直在主分支中工作，并在分支后将一些迁移应用到开发数据库。我通过添加额外的字段对我的分支中的一些模型进行了一些更改;我修改过的这些模型的表已经存在于数据库中（除了1个新模型）。
我的分支中的当前快照不是当前的实际数据库模式，通常我会AddMigraiton Merge -IgnoreChanges为我提供更新，然后进行更改。 （正确的吗？）
问题是我做了一些更改，我仍然需要应用于数据库并执行上述命令忽略这些更改。我在构建新迁移时生成的代码试图撤消（删除/更改）在主分支上应用的所有迁移，它当前还会看到我对其进行了更改的所有模型（以及其他一些模型）作为新表，并尝试创建新表而不是添加新列。
解决这个问题的最佳方法是什么？是否可以首先避免这种情况？
我在想我可以将主分支合并到我的分支中以进行迁移，但是不确定这是否能解决我的问题。
生成的任何迁移在应用于我们的生产数据库时也需要工作。
希望我已经足够好地解释了这一点。我对EF仍然很陌生，所以任何帮助都会受到赞赏。
答案 0 :(得分：2)
常见的经验法则是：Entity Framework使用的数据库的所有使用者应该具有100％相同版本的模型快照，因此整个迁移历史记录应该100％匹配连接到数据库的所有人。如果至少有一个人对模型进行了任何小的更改并创建了迁移，他应该切换到一个单独的数据库，直到更改合并到主分支，并且所有人再次拥有100％相同版本的模型快照。
让不同的人在本地对模型进行更改会带您进入这样的情况，即许多人拥有不同的模型快照，并尝试将他们的更改应用于模型到同一个数据库，从而产生以下结果：
如果您使用自己的本地数据库（或仅为您的分支创建的远程数据库），您将不会遇到这些问题。您将获得的唯一问题是合并后的快照不一致，只需在从分支进行合并后立即通过空合并迁移修复，其中包含对模型的更改。
我相信每个开发人员都必须拥有自己的数据库版本，并且只有dev应用程序才能使用dev DB，如果你托管它的话。否则你很难破坏一些其他开发人员对数据库所做的更改，而你的本地应用程序 - 以及远程 - 在他修复它之前就会被破坏。
编辑： 我还建议阅读有关在CVS团队中使用迁移的MSDN文章： https://msdn.microsoft.com/en-us/data/dn481501.aspx
每个团队成员都应具有本地开发数据库迁移 使用__MigrationsHistory表来存储迁移的内容 应用于数据库。如果您有多个开发人员生成 尝试定位同一数据库时的不同迁移（和 因此共享一个__MigrationsHistory表）将进行迁移 很困惑。
答案 1 :(得分：2)
今天发生在我身上的事情是我基本上丢失了整个 Migrations 文件夹，所以没有迁移文件，没有快照文件，什么都没有。我想对数据库做一些更新（在表上添加一个新列）。所以我遵循了这些步骤并最终让它工作（包管理器控制台中的命令）：
Add-Migration temp - 这将生成迁移文件（将重新创建整个数据库）和快照文件。显然这个 Snapshot 文件对应于当前的数据库状态；Remove-Migration（因为这也会删除快照文件），而是直接删除文件（例如在解决方案资源管理器中）。在这一点上，我有当前的快照，没有迁移；Add-Migration new_column_etc - 通过添加这个迁移，因为我有一个快照来比较，它实际上生成得很好，只显示了我所做的更改（以及我打算在数据库中更新的内容）首先）；Update-Database - 现在我更新了我的数据库并且快照文件对应于最新版本。我知道它可能与最初的要求有所不同，但在绝望的情况下，它可以提供一种将快照文件重新生成为当前版本的数据库的方法。