Pull Requests

Работа с Pull Request

Pull Requests позволяют вам сообщить другим об изменениях, которые вы внесли в ветку в репозитории на GitHub. После открытия Pull Request'а вы можете обсудить и просмотреть потенциальные изменения с коллегами и добавить последующие коммиты до того, как ваши изменения будут объединены в базовую ветку.

Из документации к Pull Request'ам на GitHub Docs

Как создавать?

Создание Pull Request'а на Github Docs

Когда создавать?

Ежедневно

Сразу после первых коммитов. К концу рабочего дня должно коммититься текущее состояние вашей ветки. Если ПР не готов к ревью - он отправляется в драфт (по этой же причине нет смысла использовать WIP в коммит месседжах: если работа в процессе - ПР находится в драфте)

Зачем?

Это необходимо для прозрачности процесса, чтобы вовремя выявить недочеты при написании кода, пока кодовая база вокруг них не разрослась, они не остались незамеченными и не превратились в легаси.

В будущем такой подход также помогает при навигации по истории коммитов.

Однако надо следить за объемом ПР - если количество файлов больше 30 и это не файлы автогенерации (зависимости, результат работы генераторов и проч.) то это уже большой ПР. Такие ПР тяжело ревьюить, а большое количество замечаний затормозит весь релиз. Можно пойти двумя путями:

1. Делать мелкие ПР в master ветку
2. Сделать один основной ПР, работать через дополнительные ПР к основному

Кого ставить в assignee?

Указываем себя, как автора. В дальнейшем это позволит делать фильтрацию по PR и получать предсказуемый результат.

Кого указывать в ревьюверах?

Лида (ментора) или если таковой отсутствует - @torinasakura

Что за статусы проверок?

У проектов могут быть настроены проверки проектов, которые выполняются при создании и обновлении Pull Request'а. В них можно получить всю необходимую информацию о выполнении тестов.

Можно ли форсить ветку (push --force)?

Можно, но только если от этого больше пользы, чем вреда. Когда можно:

1. Когда ревью еще не провели.
2. Когда в ветку еще ничего не вливали (обновленный dev)
3. Когда PR на этой ветке еще нет.

Когда нельзя:

1. Когда ревью провели. Комментарии привязываются к хешу коммитов. Если форснуть, то это уже новые коммиты, даже если в них ничего не менялось. Из-за этого весь прогресс ревью тупо слетает. В итоге ревьюверу нужно потратить время, чтобы определиться, где он оставлял ревью, а где нет.
2. Когда форсом можно ненароком ввести в заблуждение. После форса достаточно муторно посмотреть, что же в итоге изменилось. Можно, конечно, выдрать хеши и пойти в diff, чтобы посмотреть, что изменилось.

Лучше пусть будут лишние коммиты (коммиты лишними не бывают), так процесс выглядит более прозрачным и последовательным.