A bit of backgound: We use docker container to run our django project and since there are a number of us working on the project we have put migrations folder into gitignore (whether this is right or wrong is a separate matter) to avoid merge conflicts.

Everytime makemigrations are run - it's always 001_initial.py as Docker copies the git project which has no migrations in it. It's up to migrate command to figure out which changes to apply to database. It's becoming a common issue now that sometimes when there is a new field (or a field renamed) - although these changes are in myapp\migrations\001_initial.py - once migrate command is run, django thinks those changes are already in the database and it doesn't apply any migrations. We are wiping the database and re-doing the migrations which works fine for development, but obviously it doesn't work for production. There are questions relating to this and people recommended to revert to the previous migrations which seems to reset and worked for us on some occasions - for example:

python manage.py migrate myapp zero

But it doesn't work always if there are relations in database with entirely new tables (so django complains that table doesn't exist) when trying to revert and partly because our migrations in docker container always start from 001_initial.py.

Is this a django bug or are we not following any good practice hence the problem? We are thinking of removing migrations folder from gitignore which enables reverting to older migrations, however we are not entirely sure whether this would fix the issue and besides django project is run in the container - so migrations files inside the container are not commited to git repo.