Should you Commit Django Migrations to Git?

April 7, 2026 · Django

Every July, millions of animals journey between the Serengeti and Maasai Mara in search of fresh grazing land. The Great Migration features approximately 1.3 million 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 is Database Migrations?

Database migrations also called schema migrations or simply migrations are structured sets of changes designed to modify the organization of a relational database. They allow your database to evolve from its current state to a desired state, whether that means adding or removing tables and columns, splitting fields, or updating data types and constraints.

Migrations handle incremental and often reversible changes programmatically, ensuring that database updates are repeatable, shareable, and testable without risking data loss. Migration tools generate artifacts that precisely define the steps needed to move a database from one version to another.

Think of migrations as a version control system for your database schema.

Django Migrations

Django migrations allow you to apply changes made to your models such as adding a field or deleting a model—directly to the database schema. For each model, Django generates a migration file inside the migrations folder, which defines the corresponding table structure. Each table in the database is mapped to the model for which the migration was created.

Django provides several commands to manage migrations:

makemigrations – Creates a migration file containing the code for a model’s table schema.
migrate – Applies the migration to create or update tables in the database according to the schema.
sqlmigrate – Displays the raw SQL query that will be executed for a migration.
showmigrations – Lists all migrations along with their current status.

Pros and Cons of Committing Django Migrations to Git

Reasons Not to Commit Migrations

Migration conflicts: Conflicts can occur when merging branches if multiple migration files haven’t been applied to the database. Since migration files aren’t automatically merged, you may need to resolve conflicts manually.
Slower migration runs: Having many migrations can slow down the process, as Django runs through all migrations to reach the latest state. This can be mitigated by squashing migrations.

Reasons to Commit Migrations

Avoid conflicting model changes: Without committed migrations, team members might make changes to models that conflict with each other.
Manual migrations matter: Some migrations, like those that populate a new field, cannot be automatically recreated from models. If these migrations aren’t in version control, other developers won’t be able to run them.
Migrations define application state: They are part of your codebase, describing and defining the current state of your application. Committing production migrations helps manage complex migration issues.
Recommended by Django: The Django developers expect migrations to be committed to version control. According to Django documentation:

“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 create them on your development machine and then run the same migrations on your colleagues’ machines, staging, and production. Migrations produce consistent results, ensuring that what you see in development and staging is exactly what will happen in production.”

Conclusion

Solo projects: You may choose whether or not to commit migrations, but ensure you don’t modify the database schema without creating new migrations in production.
Team projects: Always commit migrations. This avoids conflicts and ensures everyone works with the same database schema.

Sources