1. Change model code to add the new field, test, and commit it to version control. Then it's merged to staging, where it's tested in a production-like environment with a recent production data snapshot. After that's approved, it goes to master/production servers.
2. git pull then restart some wsgi/worker processes
3. git checkout to desired revision and restart some wsgi/worker processes
It's perfectly fine to have models comprised of only a subset of the data they interact with.
The models do not have to reflect all fields that exist in the database.
The models only reflect information that is necessary for the application in which said models are used.
Basically, if you clobber your database, no amount of migration tooling or process will help you. Ever. It will just get in the way, to be honest, and will prevent you from doing things properly in the first place.
You missed the point of all those questions (e.g. in 2 you don't mention how the schema change gets applied to the prod database). Unfortunately I'm frankly out of patience explaining any further, so we'll have to leave it there.
2. git pull then restart some wsgi/worker processes
3. git checkout to desired revision and restart some wsgi/worker processes
It's perfectly fine to have models comprised of only a subset of the data they interact with.
The models do not have to reflect all fields that exist in the database.
The models only reflect information that is necessary for the application in which said models are used.
Basically, if you clobber your database, no amount of migration tooling or process will help you. Ever. It will just get in the way, to be honest, and will prevent you from doing things properly in the first place.