Migrations workflow
In order to avoid migrations issues in future, I advise to use this workflow. The main idea is to commit your migrations files only after getting all approvals in PR and before pushing your branch to the DEVELOP branch. Let me show this more clearly.
Let's imagine that you start working on your feature branch and first you need to add (modify/delete) a new model.
After the model successfully add (modify/delete) usually the next step is migration.
Finally, we have such picture of our git changes:
Usually, the next step is to commit these changes and continue with other development but don't hurry up.
The main idea is to leave migrations files uncommitted until the end of branch development.
Therefore, in our example, we can stage the model and context file (or separately each one)
And commit only them without migration files.
You can continue on the project and add (modify/delete) other files but need necessarily to stage them before commit and always leave migration uncommitted.
And commit your migrations files only after getting all approvals in PR and before pushing your branch to the develop branch.
What gives this approach to us?
- If our model(-s) changes again we don't need to create a new migration besides the previous. We can delete the current migration files, undo changes for Snapshot, and create only one final migration.
- Easily add new migrations to DEVELOP branch without conflicts.
Before pushing the branch with migrations need:
2.1 get all needed approvals in your PR from teammates (in our case 2 approval)
2.2 to delete these local uncommitted migrations
2.3 merge develop into the current branch (there could be new migrations with the last Snapshot)
2.4 create only one final migration, commit, push the branch and then at the nearest time merge the current branch to DEVELOP branch
Minuses:
- The migration files could be committed accidentally. In this case, need to revert the last commit.
- Every member of the team should be on the same page with this approach.