Публикация работы¶

Вы можете опубликовать свою работу на GitHub, выполнив:

git push origin ticket_xxxxx

Когда вы перейдете на свою страницу GitHub, вы увидите, что была создана новая ветка.

Если вы работаете над тикетом Trac, вам следует указать в тикете, что ваша работа доступна из ветки ticket_xxxxx вашего репозитория GitHub. Включите ссылку на вашу ветку.

Обратите внимание, что указанная выше ветка называется «topic branch» («тематическая ветка») в терминологии Git. Вы можете свободно переписывать историю этой ветки, используя git rebase для примера. Другие люди не должны основывать свою работу на такой ветке, потому что их клон будет поврежден, когда вы редактируете коммиты.

Также существуют «public branches» («публичные ветки»). Это ветки, которые другие люди должны форкать, поэтому история этих веток никогда не должна меняться. Хорошими примерами публичных веток являются ветки main и stable/A.B.x в репозитории django/django.

Когда вы считаете, что ваша работа готова к загрузке в Django, вам следует создать запрос на принятие изменений на GitHub. Хороший запрос на принятие изменений означает:

• фиксирует по одному логическому изменению в каждом, следуя стилю кодирования,

• правильно сформированные сообщения для каждого коммита: строка саммари, а затем абзацы со строками длиной не более 72 символов – см. руководства по коммиту для получения более подробной информации,

• документация и тесты, если нужны – на самом деле тесты всегда нужны, за исключением изменений в документации.

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

После создания запроса на принятие изменений вам следует добавить комментарий в соответствующий тикет Trac, описывающий, что вы сделали. В частности, вам следует отметить среду, в которой вы запускали тесты, например: «все тесты проходят под SQLite и MySQL».

Запросы на принятие изменений в GitHub имеют только два состояния: открытое и закрытое. У того, кто будет заниматься вашим запросом на включение изменений, есть только два варианта: слить его или закрыть его. По этой причине бесполезно делать запрос на включение изменений, пока код не будет готов к объединению — или достаточно близок к тому, чтобы слияние само его завершило.

Перебазирование веток¶

В примере выше вы создали два коммита: коммит «Fixed ticket_xxxxx» и коммит «Added two more tests».

Мы не хотим хранить всю историю вашего рабочего процесса в вашем репозитории. Ваш коммит «Added two more tests» будет бесполезным шумом. Вместо этого мы бы предпочли иметь только один коммит, содержащий всю вашу работу.

Чтобы переработать историю вашей ветки, вы можете объединить коммиты в один, используя интерактивное перебазирование (interactive rebase):

git rebase -i HEAD~2

HEAD~2 выше — это сокращение для двух последних коммитов. Команда выше откроет редактор, показывающий два коммита, с префиксом «pick».

Измените «pick» во второй строке на «squash». Это сохранит первый коммит и сожмет второй коммит в первый. Сохраните и выйдите из редактора. Должно открыться второе окно редактора, так что вы можете перефразировать сообщение для коммита, теперь, когда оно включает оба ваших шага.

Вы также можете использовать опцию «edit» в rebase. Таким образом вы можете изменить отдельный коммит, например, чтобы исправить опечатку в строке документации:

git rebase -i HEAD~3
# Choose edit, pick, pick for the commits
# Now you are able to rework the commit (use git add normally to add changes)
# When finished, commit work with "--amend" and continue
git commit --amend
# Reword the commit message if needed
git rebase --continue
# The second and third commits should be applied.

Если ваша тематическая ветка уже опубликована на GitHub, например, если вы вносите незначительные изменения, чтобы учесть отзыв, вам нужно будет принудительноотправить изменения:

git push -f origin ticket_xxxxx

Обратите внимание, что это приведет к переписыванию истории ticket_xxxxx - если вы проверите хэши коммитов до и после операции на GitHub, вы заметите, что хэши коммитов больше не совпадают. Это приемлемо, поскольку ветка является тематической веткой, и никто не должен основывать свою работу на ней.

После того, как удаленная ветка изменилась¶

Когда удаленная ветка (django/django) изменилась, вам следует перебазировать свою работу. Чтобы сделать это, запустите:

git fetch upstream
git rebase upstream/main

Работа автоматически перебазируется с использованием ветки, на которой вы делали форк, в примере с использованием upstream/main.

Команда rebase временно удаляет все ваши локальные коммиты, применяет вышестоящие коммиты, а затем снова применяет ваши локальные коммиты.

Если возникнут конфликты слияния, вам нужно будет разрешить их, а затем использовать git rebase --continue. В любой момент вы можете использовать git rebase --abort чтобы вернуться в исходное состояние.

Обратите внимание, что вы хотите перебазировать по удаленной ветке, а не замерджить в нее.

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

После проверки¶

Не стоит вносить в ядро большой объем кода без обсуждения с рецензентами.В этом случае часто бывает хорошей идеей добавить изменения в виде одного коммита в вашу работу. Это позволяет рецензенту легко проверить, какие изменения вы внесли.

В этом случае внесите изменения, требуемые рецензентом. Делайте коммиты так часто, как необходимо. Перед публикацией изменений перебазируйте свою работу. Если вы добавили два коммита, вы должны выполнить:

git rebase -i HEAD~2

Склейте второй коммит с первым. Напишите сообщение коммита в соответствии со строками:

Made changes asked in review by <reviewer>

- Fixed whitespace errors in foobar
- Reworded the docstring of bar()

Наконец, отправьте свою работу обратно в репозиторий GitHub. Поскольку вы не трогали публичные коммиты во время перемещения, вам не нужно принудительно отправлять (с использованием force):

git push origin ticket_xxxxx

Теперь ваш запрос на принятие также должен содержать новый коммит.

Обратите внимание, что мерджер, скорее всего, склеит ревью коммит с предыдущим коммитом.