Вклад

Настройка

Fork on GitHub

Before you do anything else, login/signup on GitHub.com and fork django-crispy-forms from https://github.com/django-crispy-forms/django-crispy-forms.

Клонируйте свой форк локально

If you have git-scm installed, you now clone your git repository using the following command-line argument where <my-github-name> is your account name on GitHub:

git clone git@github.com/<my-github-name>/django-crispy-forms.git

Требования к установке

Установите зависимости для разработки, cd-нув в папку crispy-forms, а затем выполнив:

pip install -r requirements.txt

Django-crispy-forms поставляется со скриптами git hook. Их можно установить, выполнив:

pre-commit install

Pre-commit теперь будет автоматически запускаться на git-commit и проверять соблюдение руководства по стилю (black, isort & flake8).

Build the documentation locally

If you make documentation changes they can be seen locally. In the directory where you cloned django-crispy-forms:

cd docs
pip install -r requirements.txt
make html

You can open the file _build/html/index.html and verify the changes.

Создание тематических веток и генерация запросов на вытягивание

While it’s handy to provide useful code snippets in an issue, it is better for you as a developer to submit pull requests. By submitting pull request your contribution to django-crispy-forms will be recorded by GitHub.

В git лучше всего выделять каждую тему или функцию в «ветвь темы». В то время как отдельные коммиты позволяют вам контролировать внесение небольших индивидуальных изменений в код, ветви - это отличный способ сгруппировать набор коммитов, относящихся к одной функции, или изолировать различные усилия, когда вы работаете над несколькими темами одновременно.

Хотя требуется некоторый опыт, чтобы понять, как правильно разбивать коммиты, тематическая ветка должна быть ограничена одним issue, как представлено в трекере проблем.

Also since GitHub pegs and syncs a pull request to a specific branch, it is the ONLY way that you can submit more than one fix at a time. If you submit a pull from your main branch, you can’t make any more commits to your main branch without those getting added to the pull.

Для создания ветви темы проще всего использовать удобный аргумент -b к git checkout:

git checkout -b fix-broken-thing
Switched to a new branch 'fix-broken-thing'

You should use a verbose enough name for your branch so it is clear what it is about. Now you can commit your changes and regularly merge in the upstream main branch as described below.

When you are ready to generate a pull request, either for preliminary review, or for consideration of merging into the project you must first push your local topic branch back up to GitHub:

git push origin fix-broken-thing

Now when you go to your fork on GitHub, you will see this branch listed under the «Source» tab where it says «Switch Branches». Go ahead and select your topic branch from this list, and then click the «Pull request» button.

Here you can add a comment about your branch. If this in response to a submitted issue, it is good to put a link to that issue in this initial comment. The repo managers will be notified of your pull request and it will be reviewed (see below for best practices). Note that you can continue to add commits to your topic branch (and push them up to GitHub) either if you see something that needs changing, or in response to a reviewer’s comments. If a reviewer asks for changes, you do not need to close the pull and reissue it after making changes. Just make the changes locally, push them to GitHub, then add a comment to the discussion section of the pull request.

Регулярно подтягивайте изменения из восходящего потока в свой форк

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

Для внесения изменений в восходящий поток:

git remote add trunk git://github.com/django-crispy-forms/django-crispy-forms.git
git fetch trunk

Проверьте журнал, чтобы убедиться, что изменения действительно нужны, перед слиянием:

git log ..django-crispy-forms/main

Затем объедините изменения, которые вы извлекли:

git merge django-crispy-forms/main

For more info, see https://help.github.com/fork-a-repo/

Как добиться принятия вашего Pull Request

Нам нужны ваши предложения. Но мы также хотим обеспечить стабильный опыт для наших пользователей и сообщества. Следуйте этим правилам, и вы добьетесь успеха без проблем!

Проведите тесты!

Прежде чем отправлять заявку, пожалуйста, запустите весь набор тестов django-crispy-forms через:

make test

Если у вас не установлен make, набор тестов также можно запустить через:

pytest --ds=crispy_forms.tests.test_settings --cov=crispy_forms

Первое, что сделают основные коммиттеры, это выполнят эту команду. Любой запрос на внесение изменений, не прошедший этот набор тестов, будет отклонен.

Всегда полезно добавлять тесты!

Мы на собственном опыте убедились, что код без тестов не является надежным. Если в вашем запросе есть тесты, у него больше шансов быть включенным. В противном случае ведущий попросит вас написать тесты или поможет вам в этом.

Мы используем py.test.

Кроме того, делайте свои тесты как можно более простыми. Сложные тесты в конечном итоге требуют своих собственных тестов. Мы бы предпочли видеть дублирование утверждений в тестовых методах, а не хитрые утилиты, которые волшебным образом определяют, какие утверждения нужны на конкретном этапе. Помните: Явное лучше неявного.

Не смешивайте изменение кода с очисткой пробельных элементов

Если вы измените две строки кода и исправите 200 строк проблем с пробелами в файле, разница в этом запросе будет функционально нечитабельной и будет отклонена. Устранение пробелов должно быть в отдельном запросе.

Ограничьте свои запросы на исправление одним вопросом

Запросы на исправление django-crispy-forms должны быть настолько маленькими/атомарными, насколько это возможно. Большие, широкомасштабные изменения в запросе будут отклонены, с комментариями, чтобы изолировать конкретный код в вашем запросе. Некоторые примеры:

  1. Если вы исправляете ошибку в одном классе помощника, не надо «чистить» не связанные с ним помощники. Такая очистка должна проводиться в другом запросе.

  2. Изменение прав доступа к файлу должно происходить в отдельном запросе с явным указанием причин.

Сохраняйте простоту кода!

Запомните дзен питона:

>>> python -c 'import this'

Пожалуйста, сохраняйте ваш код настолько чистым и простым, насколько это возможно. Когда мы видим более одной-двух функций/методов, начинающихся с _my_special_function or things like __builtins__.object = str, мы начинаем беспокоиться. Вместо того, чтобы пытаться разобраться в вашей блестящей работе, мы просто отклоним ее и отправим запрос на упрощение.

Более того, нехватка пикселей закончилась. Мы хотим видеть:

  • helper вместо hpr.

  • django-crispy-forms вместо dcf

  • my_function_that_does_things вместо mftdt.

Вернуться на верх