Migrations in Entity Framework in a collaborative environment

You need to manually resolve migration conflicts just like you would code conflicts. If you update and there are new migrations, you need to ensure that the metadata behind the last migration matches the current model. To update the metadata of the migration, re-issue the Add-Migration command for it.

For example, before step 17 (Update-Database) in your scenario, you should issue the following command

Add-Migration M2

This will update the metadata to bring it in sync with your current model. Now when you try and add M3, it should be blank since you have not made any further model changes.

Option 1: Add a blank ‘merge’ migration

1. Ensure any pending model changes in your local code base have been written to a migration. This step ensures you don’t miss any legitimate changes when it comes time to generate the blank migration.
2. Sync with source control.
3. Run Update-Database to apply any new migrations that other developers have checked in. ** Note:****if you don’t get any warnings from the Update-Database command then there were no new migrations from other developers and there is no need to perform any further merging.
4. Run Add-Migration –IgnoreChanges (e.g. Add-Migration Merge –IgnoreChanges). This generates a migration with all the metadata (including a snapshot of the current model) but will ignore any changes it detects when comparing the current model to the snapshot in the last migrations (meaning you get a blank Up and Down method).
5. Continue developing, or submit to source control (after running your unit tests of course).

Option 2: Update the model snapshot in the last migration

1. Ensure any pending model changes in your local code base have been written to a migration. This step ensures you don’t miss any legitimate changes when it comes time to generate the blank migration.
2. Sync with the source control.
3. Run Update-Database to apply any new migrations that other developers have checked in. ** Note:****if you don’t get any warnings from the Update-Database command then there were no new migrations from other developers and there is no need to perform any further merging.
4. Run Update-Database –TargetMigration (in the example we’ve been following this would be Update-Database –TargetMigration AddRating). This roles the database back to the state of the second last migration – effectively ‘un-applying’ the last migration from the database. ** Note:****This step is required to make it safe to edit the metadata of the migration since the metadata is also stored in the __MigrationsHistoryTable of the database. This is why you should only use this option if the last migration is only in your local code base. If other databases had the last migration applied you would also have to roll them back and re-apply the last migration to update the metadata.
5. Run Add-Migration (in the example we’ve been following this would be something like Add-Migration 201311062215252_AddReaders). ** Note:****You need to include the timestamp so that migrations knows you want to edit the existing migration rather than scaffolding a new one. This will update the metadata for the last migration to match the current model. You’ll get the following warning when the command completes, but that’s exactly what you want. “Only the Designer Code for migration '201311062215252_AddReaders' was re-scaffolded. To re-scaffold the entire migration, use the -Force parameter.”
6. Run Update-Database to re-apply the latest migration with the updated metadata.
7. Continue developing, or submit to source control (after running your unit tests of course).

MSDN have a great article on this. Please go through it.

Entity Framework Code First Migrations in Team Environments

You need to add a blank "merge" migration that will reset the snapshot of the latest migration in the .resx file. Do this using the IgnoreChanges switch:

Add-Migration <migration name> -IgnoreChanges

See here for an explanation

We are having similar issues in our environment, here is what we've figured out so far and how we got around it:

When you have changes that you have applied (update-database) but not checked in, and then you receive changes from another developer who doesn't have your changes, this is where things seem to get out of sync. In our experience, it seems like the meta data that is saved for your own changes get over written by the meta-data from the other developer when you do the update-database process. The other developer doesn't have your changes, so the meta-data that gets saved is no longer a real reflection of your database. When EF does a comparison after that, it 'thinks' that your changes are actually new again because of the meta data change.

A simple, admittedly ugly workaround is to do another migration, and wipe out it's contents so you have empty up() and empty down() methods. Apply that migration and check it into source control and let everyone sync to that. This simply syncs up all of the meta data so everyone has all of the changes accounted for.