In what way is manually tracking the needed DB changes per feature branch even possibly better? Even if you are not running your migrations automatically on dep

In what way is manually tracking the needed DB changes per feature branch even possibly better? Even if you are not running your migrations automatically on deploy, I would still check those migrations into version control. Having auto-runnable migrations checked in alongside the code that depends on them allows you to review and test those migrations as part of your normal code review and CI processes. I think there must be some misunderstanding here because I don't understand why you say either of these things: > This would mean constant churn of migration code for each branch of the repo. > it would require you to write special migration code on a release branch There should only a be at most a few migrations per feature branch and merging is only an issue when you have two feature branches with inconsistent schema definitions. You should only have to add custom migrations to a release branch to fix bugs and those should be merged back into your develop branch as soon as possible to minimize effort spend merging later.