What exactly does a --fake migrations in django?

This command is designed to work with databases already in production, with the structure previously defined or data already inserted.

We also understand that tables by nature already have the same structure as those defined in the Django project. Therefore we apply a --fake avoiding the previous migrations to be executed, they are marked as already executed in the migrations table and to be able to apply new migrations.

The migration system in Django allows the traceability of changes in the structure of tables in a database. It does not necessarily apply in production, because its use is very frequent during the development of a project.

As I said, it is a record of changes, that is, of the differences between the current version of a model and the immediate previous version. Be careful with immediate previous because it is the key of the --fake parameter.

Migration compares the differences between both versions and creates a file that creates the changes in the database. For example, if in the new version you create a new field, a script is created that creates that field in the database and fills the existing records, if any, with a default value, defined by the programmer.

To be able to reconstruct a database, then, it is necessary to travel the entire path, from the initial migration, one to one, until the last one.

But what happens are you programming in two teams or is it a team of programmers who contribute to the project. Imagine that the version of the current model is 5 and in your team you are in version 3.

With the parameter --fake you skip all the missing migrations (in this case 4) and you leave your model with the final version (that is, 5).

Actually, using it in production is a bit more risky than using it in development, because there may be missing data in the final table.

Finally, do not forget to include the migrations in your version control to ensure that you have the full outline of the changes in your database.