Gitignore for a Django project

If you are using Git for version control, you need a Gitignore file to ignore all files that don’t matter and shouldn’t be in your git repository. Think of your virtual environment and all the .pyc files. Those are both generated and can be generated by anyone that has access to your code. Therefore, it’s unnecessary to add those to your repository.

There are a lot of different file types and specific folders that you don’t need. Even outside of Django. Think about your personal settings in VS Code (if you use that). Here is a list which covers all things that you can ignore through gitignore for every Django project you start. Put this list in the root of your Django project and call it .gitignore (yes, with the dot!).

Here's the ultimate Django gitignore

# Django #
*.log
*.pot
*.pyc
__pycache__
db.sqlite3
media

# Backup files # 
*.bak 

# If you are using PyCharm # 
# User-specific stuff
.idea/**/workspace.xml
.idea/**/tasks.xml
.idea/**/usage.statistics.xml
.idea/**/dictionaries
.idea/**/shelf

# AWS User-specific
.idea/**/aws.xml

# Generated files
.idea/**/contentModel.xml

# Sensitive or high-churn files
.idea/**/dataSources/
.idea/**/dataSources.ids
.idea/**/dataSources.local.xml
.idea/**/sqlDataSources.xml
.idea/**/dynamic.xml
.idea/**/uiDesigner.xml
.idea/**/dbnavigator.xml

# Gradle
.idea/**/gradle.xml
.idea/**/libraries

# File-based project format
*.iws

# IntelliJ
out/

# JIRA plugin
atlassian-ide-plugin.xml

# Python # 
*.py[cod] 
*$py.class 

# Distribution / packaging 
.Python build/ 
develop-eggs/ 
dist/ 
downloads/ 
eggs/ 
.eggs/ 
lib/ 
lib64/ 
parts/ 
sdist/ 
var/ 
wheels/ 
*.whl
*.egg-info/ 
.installed.cfg 
*.egg 
*.manifest 
*.spec 

# Installer logs 
pip-log.txt 
pip-delete-this-directory.txt 

# Unit test / coverage reports 
htmlcov/ 
.tox/ 
.coverage 
.coverage.* 
.cache 
.pytest_cache/ 
nosetests.xml 
coverage.xml 
*.cover 
.hypothesis/ 

# Jupyter Notebook 
.ipynb_checkpoints 

# pyenv 
.python-version 

# celery 
celerybeat-schedule.* 

# SageMath parsed files 
*.sage.py 

# Environments 
.env 
.venv 
env/ 
venv/ 
ENV/ 
env.bak/ 
venv.bak/ 

# mkdocs documentation 
/site 

# mypy 
.mypy_cache/ 

# Sublime Text # 
*.tmlanguage.cache 
*.tmPreferences.cache 
*.stTheme.cache 
*.sublime-workspace 
*.sublime-project 

# sftp configuration file 
sftp-config.json 

# Package control specific files Package 
Control.last-run 
Control.ca-list 
Control.ca-bundle 
Control.system-ca-bundle 
GitHub.sublime-settings 

# Visual Studio Code # 
.vscode/* 
!.vscode/settings.json 
!.vscode/tasks.json 
!.vscode/launch.json 
!.vscode/extensions.json 
.history

What we are ignoring and not with this Django .gitignore

Migrations

A common question is: "why aren't we ignoring migrations?". Wouldn't it make sense to create the migrations on the server and then migrate them right away? Yes, in some cases that would make sense, but there is a big issue with that. You will always want to have the same migrations on your development machine as on the server. Imagine this: you want a field to be False for every record. You create a new field with default=False, in this case all fields are fields. Then you decide to change the field and change the default to True. The current fields are still marked as False since you ran that migration first. If you wouldn't commit the migration files, all fields would be True since the production server wouldn't know that it was False previously.

Next to that, Django recommends including migration files as they are part of the code base:

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.

Source

.pyc files

Python will always compile your code to byte code. This is saved in the .pyc files. You can't do much with that and we don't need it, python will create them anyway. It's best to just ignore them through .gitignore.

Written by Stan Triepels

Stan is professional web developer working mainly with Django and VueJS. With years of experience under the belt, he is comfortable writing about his past mistakes and ongoing learnings.