Из того, что я видел, большинство этих шагов выполняются на Github по соглашению, а не с помощью какого-либо официального процесса, предоставляемого Github.
Мой работодатель использует Github, я управляю большим количеством небольших проектов с открытым исходным кодом и время от времени участвую в других проектах с открытым исходным кодом.
Вот как я обычно это делал:
Автор добавляет своих коллег в качестве рецензентов:
Это варьируется от проекта к проекту, но в целом все назначенные коллеги-рецензенты являются участниками проекта .
Проекты с открытым исходным кодом, похоже, имеют грубую иерархию - возможно, их условием было бы объединение только после того, как «основной» участник дал согласие.
В магазине, где я сейчас работаю, мы объединяемся после того, как любой из полудюжины разработчиков в команде дал свое одобрение.
В редких случаях кто-то в команде может использовать комментарий, чтобы специально вызвать другого разработчика, который, по его мнению, должен проверить код перед его объединением, но в противном случае, кто бы ни пришел первым и почувствует, что делает это, может просмотреть и сделать комментарии.
Утверждение рецензента:
Утверждение, как правило, показывается, когда комментирует запрос на получение ответа «+1» или «lgtm» (выглядит хорошо для меня).
Легкие задачи:
Я также использовал флажки, но в большинстве случаев каждый комментарий по запросу извлечения считается неявной «задачей», которая решается либо:
- изменение кода, который комментирует строка
- отвечая другим комментарием
Краткий обзор того, что одобрено, а что еще необходимо пересмотреть:
Я использовал расширение Looks Good To Me для Chrome, которое дает вам такой вид на экране «Запросы на извлечение». Тем не менее, представление списка запросов по запросу, похоже, было нарушено недавними изменениями в Github.