Кращі практики для додавання .gitignore файлів для проектів Python? [зачинено]


209

Я намагаюся зібрати деякі мої налаштування за замовчуванням, і одне, що я зрозумів, що у мене немає стандарту, це файли .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 repo в тому ж дереві, що і ваше git repo !? Який монстр зробив би таке?
Daenyth

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

1
Ну я намагаюся підключити їх на StackOverflow ...: p
Давор Лучич

1
Я ще не використовував Buildout, але, мабуть, мені доведеться якось скоро… тому я заношу їх у список. Дякую!
ewall

2
Напевно, ви повинні вкладати *.svnсвої .global_gitignore, а не в окремі проекти.
коров’ячі

293

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 .po збираються на сервері окремо?
Екін Ертач

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.

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


Що має сенс. Мені подобається цей спосіб відокремлення загальної конфігурації від конкретної / локальної / приватної.
ewall

Як це працює? Тобто, як 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 Те, що згадується в іншій відповіді, не є загальним котлом, у ньому багато непотрібних речей. Згаданий тут стосується будь-якого Джанго / пітона загалом.
Ані Менон

Дійсно, вибачте за це ... На жаль, я не можу скасувати свою суботу, доки відповідь не буде змінена ...
Еммануель

6

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


Зрозумів. Оскільки Джанго не застосовує багато імен файлів та структури каталогів, важко вказати їх заздалегідь. Але я можу принаймні зазначити це, щоб я пам’ятав, коли створював новий проект.
ewall

Гадаєте, вам слід принаймні зробити так, щоб усі ваші користувачі завантажували файли в одну папку у свій медіа-каталог, наприклад. media/uploads, тож ви можете «ігнорувати» їх усіх за допомогою одного правила ...
Бернхард Валлант

4

Ось деякі інші файли, які можуть залишитися у налаштуваннях:

MANIFEST
*.egg-info

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