А их можно будет увидеть? Список всех PR, которые я не проревьюил?  Сейчас выглядит как-то так. Делается фича в ветке, когда она готова, на нее создается ревью. Когда ревью просмотрено(хотя бы одним человеком, но и то не всегда, как минимум тесты прошли), она мержится в дев. В конце проекта ветка дев мержится в релизную ветку. Так вот я в прицнипе могу смотреть свои ревью до того, как будет отрезан релиз, потому что в принципе ничего не поздно поменять, а скорее всего серьезных проблем там не найдется, потому что кто-то другой уже проревьюил.

Так MR в фича ветку же не делается. Это совсем беспредел. Если и делать, то в дев ветку, куда сливается фича ветка.

"хотя бы одним человеком, но и то не всегда, как минимум тесты прошли" Звучит как так себе практика. Смысл от ревью, если на него забивать можно?)

Невозможно никого заставить делать хорошее ревью. Смысла от плохого ревью тоже никого.

В любом случае ревью будет добровольное. Искуственные ограничения не помогут

Именно в fеature-ветку делать MR'ы. Можно даже для них настроить правила мержа, как для master. И тогда туда будут попадать только проверенные задачи. А фичу уже можно будет мержить без CR, только на тестировании.

Возвращаемся к предыдущему тезису - вопрос культуры) Оно и не должно быть принудительным. Я понимаю, что далеко не все команды дружно и слаженно работают, но это не мешает стремиться к идеалу

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

Да и в принципе, зачастую ревью больше служит для ознакомления с кодом

Есть вариант получше. Feature toggle. Каждая сабтаска делается независимо и вливается в основную ветку. Но работает только под флагом, который будет выключен до тех пор, пока все задачи не будут готовы. Так не будет накапливаться development hell в виде постоянных ребейзов и конфликтов, сопровождающих все таски до тех пор, пока последний разработчик не сделает последнюю задачу из эпика.

это не тот вариант

feature toggle имеет смысл в мастере. Я говорю, про дев ветку, которая еще не смержена в релиз

В корне не согласен. Ознакомление с кодом - это наименьший из приоритетов код-ревью. В первую очередь это для повышения качества кода и развития разработчика как специалиста

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

Но я же описываю практику. Я согласен про приоритет. Приоритет не связан с частотой

Вы описываете свою практику, как построено у вас на проектах. Это не значит, что оно так и должно быть) А я описал то, для чего код-ревью задумывался и должен использоваться

Да нет же, он для этого и используется, причем в первую очередь. Просто если ревью на код, в котором создается поджо,  или копипаста из другого места, то там нечего уже улучшать.

Поджики понятно. Насчёт копипасты - это уже место для улучшения потенциальное. Может быть можно эту копипасту вынести в единое место и не копипастить? Ревью такие проблемы как раз может подсветить

Может

Но ЧАЩЕ проблем нет. Это не значит, что ревью их не решает, когда они есть.