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!).
# 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/ *.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
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
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
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.
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.Django gitignore tips-tricks
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.