The clean way is to define the Down() method in the migration files correctly. Then you can go back to a certain version of the DB with the following command:
Update-Database -TargetMigration <Name of last migration to be applied>
Sometimes, you can also make EF happy by just adding an empty migration after the two migrations to be "merged". This empty migration is just there so EF can update its internal state and write it to _MigrationHistory correctly. This should get rid of the "Unable to update database to match the current model because there are pending changes and automatic migration is disabled." error.
To prevent the problems with migrations being created in parallel you have described, we always use the following process:
- Only one team should have changes to the DB model checked out at any time
- Before adding a new migration, always get latest version and apply
Update-Database - Only now make the changes to the POCOs / ModelBuilder / DbContext
- Add your migration with
Add-Migration and also define the Down() method - Check in your changes before anyone else is allowed to make changes to the DB model
- Track the migrations to be applied in an Excel file (for maintenance / support)
Note that model changes are tracked per DbContext, so maybe it is possible to split the DbContext into one separate context for each team. This would result one set of migrations per DbContext, i.e. team.
