@bpGusar
*spoiler*

Почему большой/объемный pull request это плохо (или хорошо)?

Ситуация такая:
было много ПР в промежуточную ветку, их ревьюила команда, к которой принадлежит разраб который сделал ПР;
далее эти все коммиты/изменения были объединены в один ПР и он стал похож на страницу с содержанием книги с десятками коммитов, в то же время к ревью подключились разрабы из других комманд и ревью затягивается еще на несколько дней;

Для меня такие большие ПР это проблема, я не понимаю как их ревьюить, они выглядят монструозно и не поддаются пониманию. И вот вопрос - как в этой ситуации быть? Стоит ли запрашивать ревью у разрабов из других команд когда происходит ревью в промежуточную ветку или же оставить этот ад как есть?

P.S Чем подробнее будет ответ тем лучше. Нужно разобраться в теме насколько можно. Спасибо )
  • Вопрос задан
  • 638 просмотров
Пригласить эксперта
Ответы на вопрос 3
было много ПР в промежуточную ветку, их ревьюила команда, к которой принадлежит разраб который сделал ПР;
далее эти все коммиты/изменения были объединены в один ПР и он стал похож на страницу с содержанием книги с десятками коммитов, в то же время к ревью подключились разрабы из других комманд и ревью затягивается еще на несколько дней;

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

Почему вы повторно ревьюите этот же код, ещё и теперь объединённый в один большой ПР? Какой смысл? У вас что-то не так с организацией ответственности.
Ответ написан
firedragon
@firedragon
Senior .NET developer
Размер имеет значение, иногда!
Ваша задача иметь пул реквест совпадающий с вашей задачей.
Если вы меняли ORM то это одно, а если добавляли розовую кнопку для входа то совсем другое.
В моей работе было и то и другое. 2х месячная работа скидывалась в основную ветку, потому что было надо.
И были мелочи потому что "вот все мы закончили этот юнит"

Придерживайтесь схемы когда любая операция в гите создает или исправляет какую то задачу
Ответ написан
Комментировать
uvelichitel
@uvelichitel
habrahabr.ru/users/uvelichitel
не поддаются пониманию
кажется это главное требование к PR -- что бы поддавался пониманию.
А по трудозатратам, разве вам есть разница ревьювить один большой или 10 маленьких? То есть, может быть, неудобства обусловлены просто неравномерностью вашей загрузки. Месяц ждёте, потом надо отревьювить вчера... Тогда за это и топить -- за равномерное распределение нагрузки, сбалансированные бизнес-процессы, эффективное использование ресурсов бла-бла-бла.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы