Svn 代码优先/现有数据库vs数据库优先和版本控制并行开发

我已经使用EF6.x很长一段时间了，我对它非常满意。然而，与大多数涉及团队的项目一样，由于某种缺陷或生产变更，您必须经常停止以“修复”主分支（主分支/主干等）中的某些内容。如果您的代码涉及一个实体数据模型，并且您所做的更改与数据库模式的更改相关，那么如果您在主干中进行这些更改，并试图将这些更改合并回已经启动的开发分支，那么事情可能会变得混乱。这是我使用DB-first方法的经验，其中包括EF-designer图

在阅读了关于这个主题的各种帖子之后，我开始重新审视代码优先方法和现有数据库。然而，至少对我们的团队来说，上述情况相当普遍。当只是C#或javascript时，更改相对容易合并到一个开发分支中，EDMX文件和其他与EF相关的工件就不是这样了

对于代码优先，如果要在主分支（生产修复程序等）中处理DB模式更改，那么我的选项似乎是：
（1） 自己更新EF相关类，并可能使用EF迁移，或…
（2） 再次运行EF模型反向工程过程，覆盖其中的内容。如果保持模型名称不变，则首先必须删除现有文件，否则向导会抱怨

对于database first，由于将导致合并冲突，似乎我在做这类事情时受到限制。因此，唯一的选择是只在单个分支中工作，如果您希望避免合并问题，那么主线分支中只能进行与代码相关的更改

如果您的团队正在使用某种类型的实体框架和版本控制（希望您是这样），那么您如何在这个非常常见的场景中管理更改

[更新]
多亏了埃里克，我想我找到了解决办法。

---

我也遇到过这种情况，但是在第一步反向工程之后，我没有看到太多关于“往返”能力的信息。所以我继续创建了一个小的虚拟数据库和一个带有类库的虚拟控制台应用程序。然后我拉了这个反向poco模板。。。更改了数据库中的一列，更新了tt文件，并且在保存后（如tt文件中所述），我的模式更改立即反映在POCO类中。真棒-这可能是我转储edmx文件的门票，我从来没有使用过它，可能会启用分支之间的代码合并。

我使用EF Reverse Poco模板，它只更新现有类，代码更新很容易合并。试试看