我已经使用EF6.x很长一段时间了，我对它很满意。然而，正如大多数涉及团队的项目一样，你必须经常停下来修复＆＃34;由于某种错误或生产变化导致主分支（主分支/主干等）中的某些内容。如果您的代码涉及实体数据模型并且您的make更改与数据库架构更改有关，那么如果您在主干中进行这些更改并尝试将追赶合并重新发送到具有此类开发分支的开发分支中，则事情会变得混乱已经开始了。这是我使用DB-first方法的经验，其中包括EF设计器图。
在阅读了有关该主题的各种帖子后，我开始重新审视现有数据库的代码优先方法。但是，上述情况相当普遍，至少对我们的团队而言如此。当它只是C＃或javascript时，更改相对容易合并到dev分支中，而不是EDMX文件和其他与EF相关的工件。
使用代码优先，如果要在主分支（生产修复等）中处理数据库架构更改，那么似乎我的选择是：
（1）自己更新与EF相关的类，并可能使用EF迁移，或者......
（2）再次通过EF模型逆向工程过程，覆盖那里的什么。如果保持模型名称相同，则首先必须删除现有文件，否则向导会抱怨。
对于数据库优先，由于会导致合并冲突，因此我似乎无法做这类事情。所以唯一的选择是只在一个分支中工作，如果你想避免合并问题，只能在主线分支中完成与代码相关的更改。
如果您的团队正在使用某种实体框架和版本控制（希望您是这样），那么您如何在这种非常常见的情况下管理更改？
[更新]
感谢Erik，我想我有一个解决方案。
我也遇到过这个问题，但是对于这次往返旅行并没有太多看法。第一个逆向工程步骤后的能力。所以我就开始创建一个小型虚拟数据库以及一个带有类库的虚拟控制台应用程序。然后我拉进了这个反向poco模板...更改了db中的一个列，更新了tt文件，并且在我保存后（如tt文件中所述），我的模式更改反映在POCO类中。真棒 - 这可能是我转储edmx文件的门票，我从不使用它，并且可能会在分支之间启用代码合并。
答案 0 :(得分：1)
我使用EF Reverse Poco模板，它只更新现有的类，代码更新很容易合并。试一试。