ревью еще можно сделать быстрым, а есть люди которые любят QA натравить и тестить ветку. Это оч быстро растягивается из дня до недели.

при этом все риски всеравно в моменте интеграции изменений

“ты вынужден чего-то ждать” - релиза или что имеется ввиду?

ну это уже вопрос почему ты ждешь. Чаще всего ждут апрува ПР-а.

но я выше привел пример ситуации когда еще хотят что б кто-нибудь руками потестил ветку

Подожди. Я сделал маленький коммит, а потом в пункте 2 делаю жирный коммит. То я вначале недоделал что-то или как?

больше ждешь - больше коммиты.

Почему?

потому что «зачем код который никак не юзается пушить в мастер».

У меня задача однозначна - я или сделал все коммиты или не все. Если не все - то нужно сидеть и делать

потому что ждёшь апрува, QA, ещё чего-то

Ну так и не пушь в мастер

если у тебя ветка отведена от мастера не важно один это коммит или 10. Все риски лежат в том какой объем изменений будет интегрирован в общий код

ты тролишь походу) Короч я выше кидал ссылку на Сэма Ньюмана - он лучше объяснит

Где я тролю? Ну просто если у вас есть проблемы при слиянии, проблемы общих изменений - то для начала выделите релизную или девелопмент ветку, а для завершения - отдавайте на одного разработчика изменения которые касаются одного места (это вопросы распределения, планирования и декомпозиции)

хочу только заметить одну важную вещь на тему «хорошо и плохо».

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

А есть продукты и кор домен - это та часть продукта которая непосредственно приносит деньги. Там обычно нужно быстро подтверждать или опровергать гипотизы и там нужны все эти CI/CD и т.д.

Какие примерно число ты подразумеваешь под “быстро проверить гипотезу"?

это НЕ эффективно. Это приводит к большому количеству wait time. И в ситуации продукта и важных для бизнеса его частей важно не сколько часов разработчик потратил на фичу а как быстро она начала окупаться на проде. Как быстро можно получить фидбэк. Потому все эти wait time которые «стандартные gitflow» добавляют это про убытки

Я просто на продукте с gitflow и релизами раз в неделю. И да, у нас не то что бы быстро проверяются гипотезы, но это связано скорее с бизнес-потребноостью постепенно и осторожно выводить новые фичи. Потому у меня вопросы, я без тролинга задаю их

а ещё психологически неприятно, что задачу вроде закончил, а ещё чёт ждёшь типа проверок каких
вроде как закончил, но надо как-то в фоне об этом помнить
ХЗ, может это мне к психологу надо 🤔