338

I'm trying to collect some of my default settings, and one thing I realized I don't have a standard for is .gitignore files. There's a great thread showing a good .gitignore for Visual Studio projects, but I don't see many recommendations for Python and related tools (PyGTK, Django).

So far, I have...

*.pyc
*.pyo

...for the compiled objects and...

build/
dist/

...for the setuptools output.

Are there best practices for .gitignore files, and where can I go for more about these best practices?

ekkis
  • 9,804
  • 13
  • 55
  • 105
ewall
  • 27,179
  • 15
  • 70
  • 84
  • 33
    This project https://github.com/github/gitignore was set up to answer exactly this question. – Tyler Dec 19 '10 at 20:22
  • 1
    Since the question is closed, I am commenting what I think should be an answer here. You might need to ignore the `.idea/` directory if you are on PyCharm IDE. This depends on the fact that if you want to share some/all project settings. [Here's](https://stackoverflow.com/questions/24516814/should-i-ignore-the-idea-folder-when-using-pycharm-with-git) a question on this – Teshan Shanuka J May 31 '21 at 08:22
  • 8
    I really hate that these "opinion-based" questions get closed. Why?? It's not a sensitive subject that will launch flame wars. No one is going to get upset in recognizing different opinions. The OP (and I) simply want some guidelines for best practices and are happy recognizing they cannot be "correct", yet still be highly useful. – Mike Williamson Nov 11 '21 at 13:04
  • PSA: no, you don't need to add `*.pyc` or `*.py[cod]` to your gitignore, unless you're working with Python 3.2 (which is from 10 years ago) or earlier – Alba Mendez Feb 23 '22 at 14:41
  • @AlbaMendez Well, the (now closed) question was from 11.5 years ago... ;) – ewall Feb 24 '22 at 15:10
  • 1
    I know, but it comes pretty high at Google. – Alba Mendez Feb 24 '22 at 17:18
  • 2
    I tried editing the question but it doesn't reopen it. I hate these "opinion-based" questions too. it's merely an opinion that a question is "opinion-based" – ekkis Dec 31 '22 at 21:53
  • 1
    There's arbitrary personal opinion and then there's experienced and educated opinion which is almost everything on stack overflow. I'm also fed up to the back teeth with uneducated admins closing questions on this grounds. They'll close the whole of SO. In this case there's even an answer that actually refers to a Github repo to establish a comprehensive capture of the breadth of expert opinion in one canonical place. – NeilG May 02 '23 at 10:59

6 Answers6

491

Github has a great boilerplate .gitignore

# Byte-compiled / optimized / DLL files
__pycache__/
*.py[cod]

# C extensions
*.so

# Distribution / packaging
bin/
build/
develop-eggs/
dist/
eggs/
lib/
lib64/
parts/
sdist/
var/
*.egg-info/
.installed.cfg
*.egg

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

# Unit test / coverage reports
.tox/
.coverage
.cache
nosetests.xml
coverage.xml

# Translations
*.mo

# Mr Developer
.mr.developer.cfg
.project
.pydevproject

# Rope
.ropeproject

# Django stuff:
*.log
*.pot

# Sphinx documentation
docs/_build/
Stephen Fuhry
  • 12,624
  • 6
  • 56
  • 55
seanrose
  • 8,185
  • 3
  • 20
  • 21
  • 1
    why should we ignore *.mo files? just for curiosity. are those gettext's .po files compiled on server separately ? – Ekin Ertaç Mar 14 '16 at 12:07
  • 6
    .mo files are the machine readable (binary) version of the .po files, and -as widely known- it's a lot better to keep binary files outside of a versioned repository, when you can (and you should, since including both .po and .mo means also keeping duplicated data in the repository, that the VCS cannot even "squash") – dappiu Jun 16 '16 at 23:26
  • 9
    Why not .DS_Store? – MaxCore Dec 05 '18 at 20:00
  • 1
    I note some other answers use `**/__pycache__` whereas this answer apparently recommends `__pycache__/` from Github. Is the latter sufficient? Why does anyone use the former? Comments here seem to indicate asterisks are not needed: https://stackoverflow.com/questions/56309100/how-to-ignore-the-same-name-directory-pycache-in-a-project – NeilG May 02 '23 at 11:15
91

When using buildout I have following in .gitignore (along with *.pyo and *.pyc):

.installed.cfg
bin
develop-eggs
dist
downloads
eggs
parts
src/*.egg-info
lib
lib64

Thanks to Jacob Kaplan-Moss

Also I tend to put .svn in since we use several SCM-s where I work.

Davor Lucic
  • 28,970
  • 8
  • 66
  • 76
  • 46
    Keeping an svn repo in the same tree as your git repo!? What kind of monster would do such a thing? – Daenyth Sep 15 '10 at 16:37
  • @Daenyth *giggle*, well not really, but I tend to find some leftover `.svn` directories lying around if I get a component from another source (specially in older components) and also I'm quite lazy so I sometimes copy checkouts instead of exporting stuff from SVN. I once even saw a guy actually committing leftover .svn dirs in GIT. You can run into all kind of weird things when working with silly people. – Davor Lucic Sep 15 '10 at 17:05
  • 4
    You should probably put the `*.svn` in your `.global_gitignore`, not in individual projects. – cowlicks Jan 15 '16 at 20:56
  • Might want to consider `venv/*` too if you use `virtualenv`. Virtualenv lets you set up a "separate" python environment for each project, so libraries don't overlap or conflict. Also helps prevent the "broken but works on my computer" problem. – SilentSteel Jan 01 '18 at 15:49
  • @SilentSteel IME venvs are stored in a central location on the system and not in the actual directory – Cruncher May 03 '20 at 15:37
41

Covers most of the general stuff -

# Byte-compiled / optimized / DLL files
__pycache__/
*.py[cod]
*$py.class

# C extensions
*.so

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

# PyInstaller
#  Usually these files are written by a python script from a template
#  before PyInstaller builds the exe, so as to inject date/other infos into it.
*.manifest
*.spec

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

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

# Translations
*.mo
*.pot

# Django stuff:
*.log
local_settings.py
db.sqlite3

# Flask stuff:
instance/
.webassets-cache

# Scrapy stuff:
.scrapy

# Sphinx documentation
docs/_build/

# PyBuilder
target/

# Jupyter Notebook
.ipynb_checkpoints

# pyenv
.python-version

# celery beat schedule file
celerybeat-schedule

# SageMath parsed files
*.sage.py

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

# Spyder project settings
.spyderproject
.spyproject

# Rope project settings
.ropeproject

# mkdocs documentation
/site

# mypy
.mypy_cache/

Reference: python .gitignore

Ani Menon
  • 27,209
  • 16
  • 105
  • 126
  • 1
    @Emmanuel What is mentioned in the other answer is not a generic boilerplate, it has many unnecessary things. The one mentioned here are for any Django/python generically. – Ani Menon Jul 13 '19 at 18:05
17

local_settings.py, for django projects.

*~ for all projects.

Ofri Raviv
  • 24,375
  • 3
  • 55
  • 55
  • That makes sense. I like this method of separating the general config from the specific/local/private. – ewall Sep 15 '10 at 18:05
  • How does this work? That is, how does Django or Python know when the environment is local and when it is production? – MadPhysicist Jul 07 '17 at 17:09
7

One question is if you also want to use git for the deploment of your projects. If so you probably would like to exclude your local sqlite file from the repository, same probably applies to file uploads (mostly in your media folder). (I'm talking about django now, since your question is also tagged with django)

Bernhard Vallant
  • 49,468
  • 20
  • 120
  • 148
  • Understood. As Django doesn't enforce much of a file name and directory structure, it's hard to specify these in advance. But I can at least make a note of it so I remember when I'm creating a new project. – ewall Sep 15 '10 at 18:06
  • Well guess you should at least make it common to have all your user uploaded files in ONE folder in your media dir, eg. `media/uploads`, so you can 'ignore' them all with one rule... – Bernhard Vallant Sep 15 '10 at 18:44
5

Here are some other files that may be left behind by setuptools:

MANIFEST
*.egg-info
jathanism
  • 33,067
  • 9
  • 68
  • 86
  • I think I might leave these out of my default, because some of my projects have setuptools distributions that would need 'em. But for plugins and such, yes. – ewall Sep 15 '10 at 18:04