Лучшие практики для добавления файла .gitignore для проектов Python? [закрыто]


210

Я пытаюсь собрать некоторые настройки по умолчанию, и я понял, что у меня нет стандарта для файлов .gitignore. Есть отличный поток, показывающий хороший .gitignore для проектов Visual Studio , но я не вижу много рекомендаций для Python и связанных с ним инструментов (PyGTK, Django).

Пока у меня есть ...

*.pyc
*.pyo

... для скомпилированных объектов и ...

build/
dist/

... для вывода setuptools.

Каковы некоторые рекомендации для файлов .gitignore, и где я могу получить дополнительную информацию об этих рекомендациях?


16
Этот проект github.com/github/gitignore был создан, чтобы ответить именно на этот вопрос.
MatrixFrog

1
.. Только не забудьте добавить github.com/github/gitignore/blob/master/Python.gitignore, так как это также проект Python.
Фабио Сантос

1
просто зайдите в gitignore.io и наберите python, чтобы получить стандартный файл,
Bhanu Sinha

Ответы:


64

При использовании buildout у меня следующее в .gitignore(вместе с *.pyoи *.pyc):

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

Благодаря Джейкобу Каплан-Моссу

Также я склонен вставлять, .svnтак как мы используем несколько SCM, где я работаю.


35
Хранить репозиторий SVN в том же дереве, что и репозиторий Git !? Какой монстр будет делать такие вещи?
Дениф

@Daenyth хихикать , ну не очень, но я , как правило , найти какие - то оставшиеся .svnкаталоги валяется , если я получаю компонент из другого источника (особенно в старых компонентах) , а также я очень ленивым , поэтому я иногда скопировать извлечения вместо экспорта вещи из SVN , Однажды я даже видел парня, фактически совершающего оставшиеся .svn dirs в GIT. Вы можете столкнуться с разными странными вещами, работая с глупыми людьми.
Давор Лючич

1
Ну, я пытаюсь подключить их к StackOverflow ...: p
Давор Лючич

1
Я еще не использовал Buildout, но, вероятно, скоро это понадобится ... поэтому я внесу их в список. Спасибо!
2010 г.

2
Вы должны, вероятно, положить *.svnв ваш .global_gitignore, а не в отдельных проектах.
петли

294

У Github есть отличный шаблон .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/

1
почему мы должны игнорировать файлы * .mo? просто для любопытства. .po файлы этих gettext скомпилированы на сервере отдельно?
Экин Эртач

4
Файлы .mo являются машиночитаемой (двоичной) версией файлов .po, и, как известно, гораздо лучше хранить двоичные файлы вне версионного хранилища, когда вы можете (и должны это делать, поскольку включаете оба .po и .mo означает также хранение дублированных данных в репозитории, которые VCS не может даже "раздавить")
dappiu

5
Почему бы не .DS_Store?
MaxCore

Я действительно путают, почему они .python-versionв .gitignoreздесь: github.com/github/gitignore/blob/master/Python.gitignore#L82
aceofbassgreg

16

local_settings.py , для проектов django.

* ~ для всех проектов.


В этом есть смысл. Мне нравится этот метод отделения общего конфига от конкретного / локального / частного.
2010 г.

Как это работает? То есть, как Django или Python узнают, когда среда является локальной, а когда - рабочей?
MadPhysicist

13

Охватывает большинство общих вещей -

# 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/

Ссылка: python .gitignore


Это уже упоминалось выше!
Эммануэль

@ Emmanuel То, что упоминается в другом ответе, не является общим шаблоном, в нем много ненужных вещей. Упомянутый здесь для любого Django / python.
Ани Менон

Действительно, извините за это ... К сожалению, я не могу отменить свое понижение, пока не отредактирован ответ ...
Эммануэль

6

Один вопрос, если вы также хотите использовать git для развертывания ваших проектов. Если это так, вы, вероятно, хотели бы исключить свой локальный файл sqlite из хранилища, то же самое, вероятно, применимо к загрузке файлов (в основном в вашей медиа-папке). (Я сейчас говорю о django, так как ваш вопрос также помечен как django)


Понял. Поскольку Django не применяет большую часть имени файла и структуры каталогов, их сложно определить заранее. Но я могу, по крайней мере, отметить это, поэтому я помню, когда я создаю новый проект.
2010 г.

Ну, думаю, вы должны, по крайней мере, сделать так, чтобы все загруженные пользователем файлы были в ОДНОЙ папке в вашем медиа-каталоге, например. media/uploadsтак что вы можете «игнорировать» их всех одним правилом ...
Бернхард Валлант

4

Вот некоторые другие файлы, которые могут быть оставлены программой установки:

MANIFEST
*.egg-info

Я думаю, что я мог бы оставить их вне моего значения по умолчанию, потому что некоторые из моих проектов имеют дистрибутивы setuptools, которые потребуют их. Но для плагинов и тому подобного, да.
2010 г.
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.