skyANAу нас есть code review pull request-ов

Я вообще-то не об этом спросил. Ну да ладно, видимо это секрет

skyANAhVostt, мне не интересно выяснять, что такое code review по комментариям, я написал какое оно у нас. Никаких секретов.

Не хочешь отвечать, и не надо. Никто же тебя не принуждает.
Но дурака-то зачем включать? Просто по приколу?

П.С. «мне не интересно выяснять» — это конечно требует IQ over 10000, особенно, когда ты сам об этом же и писал...

skyANAhVosttСтёр коммент и всё пучком?
Пул реквест не пройдёт ревью и не получит апрува :)

skyANAИ если видно, что удалили комментарий вида "поправить говнокод", а в самом говнокоде ни строчки не изменилось, то тупо decline с комментарием: "таки надо поправить".

Ну вот в этом и была суть вопроса, наконец-то :)


skyANAОчевидно же, если ты конечно знаешь, что такое pull request и code review :)

Не понимаю при чём тут pull request, вопрос состоял в том, обращают ли внимание во время code review на комментарии типа TODO, или нет. А когда это review происходит вообще фиолетово, хоть в полнолуние.

skyANAЛюбое изменение в коде - это pull request.

Это смотря куда.

skyANAhVostt, смотря куда pull request? А есть варианты?

В master pull request, в остальные ветки — зачем?

skyANAа для тебя это было секретом? Странно, это же элементарная логика

Я уже объяснял свою позицию: TODO комментарии это личный инструмент разработчика, нечего ревьюверу на них смотреть.


skyANAhVosttВ master pull request, в остальные ветки — зачем?о чем ты?

Не знаешь, что такое ветки? :)

Про Git-Flow что-нибудь слышал?

skyANAну для тебя личный, а для нас нет

Это понятно, именно это я выяснял у тебя.

skyANAЗачастую TODO комментарии появляются потому, как разработчик договорился с ревьюверами, что поправит данное место в такой-то версии, или после того как сделает то-то.

Ну вот, спасибо за ответ.


skyANAЧто такое ветки и в меркуриале и в гите знаю, о Git-Flow слышал. Прямо объясни, к чему ты это упомянул?

О том, что продуктивная ветка master, в остальные можно пуллить без пулл реквестов, я об этом.

skyANAПонял тебя. Но у нас feature per branch и все наоборот.

Небольшая команда в отдельной ветке пилит свою фичу. Отдельный разработчик делает себе ветку для реализации отдельной истории (Story), или задачи (Task), или багфикса.
Соответсвенно из своей ветки в ветку фичи pull request, что ревьювится внутри команды.
А в мастер уже сливается готовая фича, или не сливается, если команда не успела запилить её к текущему релизу :)

Прикольно, чисто по-человечески такая модель выглядит очень логично.

Но при интенсивной «агильной» CI разработке мы нашли, что git-flow гораздо эффективней:

origin/develop -- это ветка и стенд, куда пулятся изменения для текущей итерации

feature/sss-xxx - это фичи-бранчи (sss-xxx номер таска в джире), при чём:

origin/feature/sss-xxx -- long story фичи, которые разрабатываются усилиями нескольких разработчиков и под неё может даже подниматься стенд (довольно быстро)

local/feature/sss-xxx -- short story фичи и багфиксы, которые разрабатываются усилиями одного разработчика в рамках одного-двух раб. дней максимум, затем сразу сливаются в develop не порождая новой ветки. если вдруг выясняется, что это вовсе не short, то ветка создаётся пуллом.

origin/release/x.x.0 -- ветка и стенд стабилизации версии, где собственно и происходит ревью и отработка замечаний, юнит- и интеграционное тестирование и отработка QA тест-планов. собирается из develop. все пуллы в эту ветку, только через реквест.

origin/hotfix/x.x.x -- ветка и стенд для хотфиксов, пуллы только через реквест. обычно не живёт больше одного-двух дней.

origin/master -- выливается стабилизированная версия из release или хотфиксы из hotfix.

такая модель прекрасно себя показывает долгое время.

комменты TODO же часто дают проходной билет некоторым участкам кода, если пояснение адекватное (типа, вот это норм работает, но буду ещё рефакторить в след. версии, потому что, бла-бла-бла).

skyANA,

да во всём. что конкретно интересует?

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

я сравниваю, и git-flow получается по всем параметрам эффективней для CI, так как есть опыт работы по другим моделям, включая feature per branch (ещё на старом добром Mercurial).

но понятно, что ещё всё зависит от проекта и команды, но тут уже рассуждать надо в контексте таких проектов.

skyANA,

если мы каждый пулл в ветку разработки будем принимать только через реквест и аппрувить-деклайнить его, то КПД разработки упадёт в разы, и не думаю, что это сильно отразится на качестве результата.