Should I Be Adding the Django Migration Files in the .Gitignore File

Should I be adding the Django migration files in the .gitignore file?

Quoting from the Django migrations 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 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.

If you follow this process, you shouldn't be getting any merge conflicts in the migration files.

When merging version control branches, you still may encounter a situation where you have multiple migrations based on the same parent migration, e.g. if to different developers introduced a migration concurrently. One way of resolving this situation is to introduce a merge_migration. Often this can be done automatically with the command

./manage.py makemigrations --merge

which will introduce a new migration that depends on all current head migrations. Of course this only works when there is no conflict between the head migrations, in which case you will have to resolve the problem manually.

---

Given that some people here suggested that you shouldn't commit your migrations to version control, I'd like to expand on the reasons why you actually should do so.

First, you need a record of the migrations applied to your production systems. If you deploy changes to production and want to migrate the database, you need a description of the current state. You can create a separate backup of the migrations applied to each production database, but this seems unnecessarily cumbersome.

Second, migrations often contain custom, handwritten code. It's not always possible to automatically generate them with ./manage.py makemigrations.

Third, migrations should be included in code review. They are significant changes to your production system, and there are lots of things that can go wrong with them.

So in short, if you care about your production data, please check your migrations into version control.

Should I be adding the Django migration files in the .dockerignore /.gitignore file?

No. The migration files are there so you can update your database without destroying it and rebuilding it from scratch (or doing the sql update statements by hand).

So you definitely want to track them in your version control.

During development, a classic scenario would be

1. write code
2. make migrations
3. apply migrations on your dev database
4. test the changes locally
5. check in and push the commit to your production server
6. execute the migrations (so only do python manage.py migrate) in production

Edit: I forgot to answer your docker question. Usually you put your source code in a volume outside the container, that you then mount into the container. So you can do docker development like this. That way the migration files and up in your codebase and you can track it.

git and django migrations: ignore the migrations files

You should absolutely keep migrations in your repo! With some projects, it makes sense to include initial data or other functions in the migrations by editing them, so setting up each developer's environment by automatically generating them from models.py won't work for every project.

If Tom and Bob both make changes that are independent of each other (Tom adds one field, Bob adds another), the migrations files will work when you create a merge migration. Tom and Bob may have to coordinate if they conflict:

$ python manage.py migrate
CommandError: Conflicting migrations detected; multiple leaf nodes in the migration graph: (0002_mymodel_my_field_tom, 0002_mymodel_my_field_bob in myapp).
To fix them run 'python manage.py makemigrations --merge'

$ python manage.py makemigrations --merge
Merging myapp
  Branch 0002_mymodel_my_field_bob
    - Add field my_field_bob to mymodel
  Branch 0002_mymodel_my_field_tom
    - Add field my_field_tom to mymodel

Merging will only work if the operations printed above do not conflict
with each other (working on different fields or models)
Do you want to merge these migration branches? [y/N] y

Created new merge migration /myapp/migrations/0003_merge_20170517_1445.py

Here's a good read:

https://www.algotech.solutions/blog/python/django-migrations-and-how-to-manage-conflicts/

How to add all of the migrations/ to git .gitignore file in django?

You can add "**/migrations/*" to your .gitignore file, this will add all folders and it's contents called migrations to git ignore. More informations here

How to ignore migrations but __init_.py?

You could use .gitignore. Lines prefixed with a bang (!) are not excluded from gitignore.

So your .gitignore file will look something like

_migrations/*
!_migrations/__init__.py

This would ignore everything in _migrations apart from __init__.py.

To remove files already committed, you can use git rm with the --cached flag...

--cached
Use this option to unstage and remove paths only from the index. Working tree files, whether modified or not, will be left alone.

eg

git rm --cached _migrations/0001_initial.cpython-37.pyc

Finally, I'd also disagree with the statement about not committing migrations. In my option committing them is exactly what you want to be doing. It ensures that instances of the database are consistent across environments. Whilst many migrations in Django are generated code, this isn't always the case. Possible the most common place you'll find a migration written by hand is when someone has made a data migration.

In short, commit the migration .py files but exclude all .pyc files.

Stopping ignoring migration files in git for a Django Project

I think the only way is to copy over all the migrations from production server to your repo then commit them. This is most likely a manual process because your production server is the only place that tracks all migrations. You don't need to worry about how to migrate your production server because it keeps the original copy. However, all these should be done before any new migrations are added and applied.

After all is fixed, you should create new migrations in your local dev environment, add to git and push your migration to production then apply the migration. Remember to have your CI or something else check for duplicate migration files.

Git file problem when migrating in Django

This is expected behavior. Git isn't doing anything at all to files it ignores. That means if .pyc files are created while you have one branch open, then you switch to another branch, nothing will happen to the .pyc files, because all you've done is switch git branches, and those files are ignored by git.

If you like, you can add a post-checkout hook that deletes all pycache directories and .pyc files each time you check out a branch.

---

Related Topics