Поток Github относительно запроса на извлечение

Question

Я пытаюсь предложить рабочий процесс с использованием GitHub. Я имею в виду, что в репозитории GitHub будет две ветви: master и dev. Другие разработчики раскошелиться на своих местных жителей. Скажем, человек А, разработал новую функцию в ветке feature-1 в своей локальной сети, отправил ее в ветку dev репозитория GitHub и сделал запрос на извлечение. Затем все разработчики подключат ветку GitHub dev к своим локальным пользователям и протестируют код. Если все в порядке, тогда объедините ветку dev в master.

Я занимался исследованиями по этому поводу, и все, что я получил, это сделал запрос на выборку. Что другой разработчик сделает, я просто ПРОЧИТАЮ КОД И КОММЕНТАРИЙ. Никаких реальных испытаний вообще.

Может кто-нибудь прояснить это? Я подумал, выполнив pull-запрос, все разработчики получат уведомление, а затем вытащат код, внесут некоторые ФАКТИЧЕСКИЕ изменения в код (а не просто прочитают и прокомментируют) и отправят его в тот же самый pull-запрос, созданный ранее.

Answer 1

В конечном счете, «что делать при проверке» зависит от вашего конкретного рабочего процесса / команды.

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

Если вы хотите, чтобы разработчики редактировали код как часть рецензирования, то у меня нет предложений, как управлять этим.Я думаю, что это просто не имеет смысла (кто рецензирует рецензента?), Но я привел свои рассуждения ниже.

---

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

Предполагается, что человек, который написал оригинальный кодобладает самыми современными знаниями о предмете / бизнес-требованиях / технических ограничениях, и поэтому предложения (и их обоснование) должны быть оценены ими.Опять же, это вещь, связанная с рабочим процессом / командой.