Прежде всего сделайте fork шаблонного проекта. Как это сделать можно прочитать тут. Это самый быстрый способ создать репозиторий. После этого его можно локально клонировать себе на компьютер:
git clone <ссылка на репозиторий>После того как скопируете репозиторий, скорее всего, вы будете находиться в main-ветке.
Как правило, ветка main (master) содержит в себе prod-код, т.е. именно из этой ветки проект будет катиться. Поэтому сама разработка из этой ветки обычно не ведется, туда делают merge финальных изменений.
Создадим ветку dev:
git checkout -b devDev — чаще всего общая тестовая ветка. От dev-ветки ответвляются «фича-ветки», где добавляется весь новый функционал. Для каждого нового функционала лучше создавать отдельную фича-ветку, а уже потом объединять их и тестировать все вместе в dev-окружении.
Создадим фича-ветку:
git checkout -b <<название ветки>>После чего создается pull request.
Pull request позволяет другим разработчикам провести ревью и оставить какие-то комментарии по поводу написанного кода, прежде чем проверять его в деве и тем более катить на прод.
В файле .gitignore принято писать, какие файлы не должны сохраняться в облачный репозиторий. Это какие-то локальные конфиги, файлы библиотек, специфичные файлы для вашего IDE или операционной системы. В общем, все, что не связано напрямую с работой проекта, не должно шариться между разными компьютерами и вдруг уезжать на прод.
Самый простой способ составить подходящий .gitignore файл — воспользоваться ресурсом gitignore.io
Там вы прописываете. Python, venv, IDE которую вы используете и в результате вы получаете уже готовый вариант файла, который вы можете вставить локально в файл .gitignore.
После создания .gitignore можно не бояться запушить что-то ненужное и спокойно использовать команду
git add . Виртуальное окружение позволяет разделять проекты, зависимости и даже версии языка.
Пример. Есть два проекта. Один использует библиотеку example версии 1, второй версии 2. Они не могут существовать одновременно, и версии могут конфликтовать из-за каких-то других зависимостей. Поэтому мы создаем два виртуальных окружения, каждое для своего проекта. Pycharm может создавать их автоматически. Python будет видеть только библиотеки из своего виртуального окружения, что существенно облегчит сосуществование множеству проектов на одном компьютере.
Создадим:
python -m venv <название окружения>
Задать версию языка для виртуального окружения, например 3.9:
python3.9 -m venv <название окружения>
Обратите внимание, что для этого нужно чтобы эта версия была установлена в системе.
Для linux/MacOS:
source <название окружения>/bin/activateДля Windows:
<название окружения>\Scripts\activate.batВ файле requirements.txt принято записывать зависимости проекта. Это набор библиотек, без которых проект не сможет запуститься. Добавляя в проект использование новой библиотеки, обязательно нужно записать ее в requirements. Это убережет в дальнейшем ваше время — если локально проект будет удален, а также время других разработчиков. При деплое в облако зависимости обычно тоже устанавливаются из этого файла.
Пишутся только те зависимости, которые непосредственно вызываются в коде. Если нужны какие-то библиотеки для работы других библиотек, они обычно ставятся автоматически при установки основных. Это позволяет не перегружать файл лишними библиотеками.
Пример файла:
aiohttp==3.8.1
black==22.6.0
freezegun==1.2.1
pytest==7.1.2
pytest-aiohttp==1.0.4
Из файла понятно, что при установке фиксируется версия. Это необязательно, но позволяет вручную следить за версией. Если в новой версии из библиотеки будет удалено что-то важное для проекта, то ничего не сломается, потому что мы фиксируемся на старой версии. В дальнейшем мы можем вручную обновить версию и сразу проследить, что при обновлении все работает как нужно. Либо что-то починить, если сломалось.
Установить все необходимые библиотеки можно при помощи команды…
pip install <библиотека>…либо:
pip install -r requirements.txtЛучше всего ставить библиотеки в виртуальное окружение.
Библиотека для автоматического форматирования кода. Рекомендуется использовать, чтобы код был читаемым и соответствовал pep8. Для применения потребуется поставить библиотеку в виртуальное окружение.
Применить:
black <файл/папка>
В файле pyproject.toml можно сконфигурировать библиотеку. Например.
[tool.black]
line-length = 80
target-version = ['py39']
exclude = '''
/(
\.eggs
| \.git
| \.hg
| \.mypy_cache
| \.tox
| \.venv
| _build
| buck-out
| build
| dist
| migrations
)/
'''
Отсюда будет понятно: какая максимальная длина строки, стандарту какой версии следовать, какие файлы не надо трогать — в том числе и при проверке, например, в пайплайне.