Migrations using git-flow

[AlexandrTsvetkov]

In our project we use git-flow methodology to manage our codebase. Which means that our production code in master branch and our development in develop branch.

Let assume that I have this situation(see attached picture):

In each commit you can see comment such as Migration {number}, where number is current datetime when migration was added to project(default name rules provided by ef core).
Migrations 1-5 were added as a part of our development process(doing new features).
Migration 6 was added as a part of bugfix
master branch always deployed to server, so it means that Migration 6 applied to production database and 1-5 not.

And now, I want to merge master branch to develop. So, my question is, is it possible to kind of rebase my Migrations 1-5 to my Migration 6?
I know, that I can remove all my Migrations from develop branch. Merge branch master to dev and create new migration. But in this case all previous Migrations 1-5 will be only one Migration 7 which might be very big and worst part, I can lose data migrations(sql command written by hand to migrate data).

Thanks.

[ajcvickers]

Triage: Moving to "Discussions" and pinging @bricelam

[bricelam]

See Migrations in Team Environments. If there are no conflicts in your ModelSnapshot when merging, you don't really need to rebase them.

Today, migrations aren't a graph like git commits. This makes them a lot more forgiving. We've considered making them more graph-like in issues like #1911 and #2174, but haven't bothered to yet.

If you want to manually rebase them, the steps would be:

1. Make the migration ID higher than the new base migration. The ID is saved in the Migration attribute of the .Designer file.
2. Merge the new base migration's backing model in the .Designer into the rebased migration. This model enables re-building parts of the database schema for certain operations. It's rarely used, so this step may actually be optional. If you skip it, be sure to review the migration scripts to make sure it's not rebuilding (dropping and re-creating) anything. (This issue can actually happen today outside of rebasing. See Migrations: Team environments can break rebuilds #996)
3. If there were conflicts in step 2, you also need to resolve them in the Up and Down methods