- Published on
Should you Commit Django Migrations to Git?
Table of Contents
About the image: Around July of each year, millions of animals migrate between the Serengeti plains and the Maasai Mara in search of fresh pasture. The Great Migration is one of the most impressive natural events worldwide, involving some 1,300,000 blue wildebeest, 500,000 Thomson's gazelles, 97,000 topi, 18,000 common elands, and 200,000 Grant's zebras. Photo by David DiGregorio.
What are Database Migrations?
Database migrations, also known as schema migrations, database schema migrations, or simply migrations, are controlled sets of changes developed to modify the structure of the objects within a relational database. Migrations help transition database schemas from their current state to a new desired state, whether that involves adding tables and columns, removing elements, splitting fields, or changing types and constraints.
Migrations manage incremental, often reversible, changes to data structures in a programmatic way. The goals of database migration software are to make database changes repeatable, shareable, and testable without loss of data. Generally, migration software produces artifacts that describe the exact set of operations required to transform a database from a known state to the new state.
You should think of migrations as a version control system for your database schema.
Django Migrations
Django migrations are a way of applying changes that we have made to models (adding a field, deleting a model, etc.) , into the database schema. Django creates a migration file inside the migration folder for each model to create the table schema, and each table is mapped to the model of which migration is created.
Django provides the various commands that are used to perform migration related tasks. After creating a model, we can use these commands.
makemigrations: It is used to create a migration file that contains code for the tabled schema of a model.migrate: It creates table according to the schema defined in the migration file.sqlmigrate: It is used to show a raw SQL query of the applied migration.showmigrations: It lists out all the migrations and their status.
Pros and Cons of Committing Migrations to Git
Reasons Not to Commit Migrations to Git
-
Migration conflicts. This can easily happen when merging branches. If you have a migration file that has not been applied to the database, and you merge a branch that has a migration file that has not been applied to the database, you will have a conflict. This is because the migration files are not automatically merged. You will have to manually merge the migration files.
-
Runnign migrations can get slow if you have a lot of migrations. This is because Django has to run through all the migrations to get to the latest migration. This can be avoided by squashing migrations.
Reasons to Commit Migrations to Git
-
if not, people would make potentially conflicting changes to the model without knowing.
-
Migrations are not always automatically generated. For example, if you add a new field to a model, you might write a migration to populate the field. That migration cannot be re-created from the models. If that migration is not in version control, then no-one else will be able to run it.
-
Migrations are part of the code as they describe and define the state or the application. Commit your production migrations to master, this helps you to prepare for and manage any migration issues you'll face when your app becomes complex.
-
The Django developers assume you'll have them in source control and they go ahead to say:
The reason that there are separate commands to make and apply migrations is because you’ll commit migrations to your version control system and ship them with your app; they not only make your development easier, they’re also usable by other developers and in production.
-
The Django documentation recommends you do so):
The migration files for each app live in a “migrations” directory inside of that app, and are designed to be committed to, and distributed as part of, its codebase. You should be making them once on your development machine and then running the same migrations on your colleagues’ machines, your staging machines, and eventually your production machines. Migrations will run the same way on the same dataset and produce consistent results, meaning that what you see in development and staging is, under the same circumstances, exactly what will happen in production.
Conclusion
-
If you are working on a project by yourself, you can maybe choose to commit your migrations to git or not. If you are not committing your migrations to git, you should make sure that you are not making changes to your database schema without creating a new migration in production.
-
The better option especially if you are working on a project with a team, is that you should definitely commit your migrations to git. This will help you avoid conflicts and make sure that everyone is working with the same database schema.