Работа с Pull Request

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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