-
Notifications
You must be signed in to change notification settings - Fork 6
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 push the branch with migrations need:
2.1 to delete these local uncommitted migrations
2.2 merge develop into the current branch (there could be new migrations with the last Snapshot)
2.3 create only one final migration and push the 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.