我已经在一个全新的项目上使用Entity Framework代码进行了一段时间的迁移，到目前为止他们在应用程序的主干版本上工作得很好。
但是，由于我们正在进行多个工作流，因此我们现在正处于创建分支机构的项目中。作为最后一部分工作的一部分，我们意识到跨分支机构使用迁移可能会有问题 - 所以我的问题是人们找到了最好的方法来管理它？
例如（为了讨论，我显然简化了这些）：
分支A： 开发人员1添加了一个“Add-UserDateCreated”迁移，它向User实体添加了一个字段。迁移文件包含添加字段的代码，并且当时具有模型状态。
分支B： 开发人员2添加了一个“Add-UserMiddleName”迁移，它向User实体添加了另一个字段。迁移文件包含添加字段的代码，并且当时具有模型状态（但显然没有在其他迁移中添加字段）。
这些迁移在他们的分支上工作正常，但是当你将它们合并回主干时，你会陷入困境：
这意味着真正避免这些问题的唯一方法是为每个分支处理数据库的不同副本，在合并到主干时忽略迁移，并在合并时添加一次主迁移完成（在数据库的主干版本上） - 但是在一次迁移中你可能最终会有很多变化，这绝不是一个好主意（并且还会丢失你在迁移类中编写的任何自定义代码）。
那么其他人如何处理这种情况呢？我很想知道别人的意见。
*我很好奇这会在现实世界中造成什么问题，如果有人知道的话？
答案 0 :(得分：5)
当您在分支机构上工作并需要迁移时，您始终需要考虑其他（活动）分支的状态。例如，如果主干上存在您在分支上没有的迁移，则应在创建新迁移之前将它们合并到分支。在分支上创建迁移后，将其合并回主干可能是个好主意。
因此，在您的示例中，开发人员A和B需要相互通信。开发人员B，意识到需要迁移，应检查是否已完成其他迁移并将其合并到她的分支，然后再创建＆＃34;中间用户名＆＃34;迁移。
我发现将迁移视为整个团队的死锁是有用的（如果这对你有意义的话。）新的迁移或创建它们的计划应该在日常站立中提到。有时，当事情繁忙时，将所有迁移的列表保存在白板上供所有团队成员查看可能是有用的。
我还发现，迁移是小型提交至关重要，这使得它们可以在分支之间轻松移植。
还应该注意的是，例如，像Git一样，使用适合分支，合并和挑选的版本控制系统是有帮助的。