·>Флаги можно делать и compile-time, и build-time.

Это усложняет поддержку кода. При разработке новых фичей придется учитывать присутствие в коде этой отложенной (на неопределенный срок) фичи.

m>> А у QA может просто не быть свободного времени на тестирование корректной работы "переключателя".
·>Это какая-то вялая отмаза. Если код недостаточно тестируется, то он может быть недостаточно качественным. И тут неважно переключатель тут тестируется или что-то ещё.

Это работает, если более-менее понятно, что спрятанная за переключателем фича точно попадет в релиз и в какие сроки попадет.
Т.е. QA могут просчитать, что они потратят время на тестирование фичи сейчас, но сэкономят позднее.
Для экспериментальных фичей с неопределенным будущим это не годится.

m>> Т.е. это не что иное, как Throw-away integration branch, описанный в документации по git.
·>Ну если почитать этот параграф повнимательнее, и ещё следующий "Branch management for a release", то можно заметить, Throw-away branch больше для демок и экспериментов, чем часть release-пайплайна. Т.е. основная разработка и тестирование всё равно ведётся отдельно в и в релиз уходит таг, т.е. то за что я топлю. По твоей же схеме QA происходит только в Throw-away branch, потом всё перезаливается второй раз (удваивая усилия на мержы-конфликты) в другой бранч и тут же объявляется релизом, без QA. То что результат мержа не тестируется — меня удивляет больше всего. А если перетестируете всё, то это удваивает нагрузку и на QA, а потом совершенно неожиданно: "у QA может просто не быть свободного времени".

QA пишут интеграционные автотесты. Они прогоняются на каждом build`е, в т.ч. после merge. Вручную результат merge не проверяется.

·>Это вообще неясно как организовать надёжно.
·>Как и в каких единицах измерить "существенность пересечения"?
·>Как детектить неявные пересечения? Даже изменения в разных файлах могут давать логические пересечения — конфликта vcs нет, а код не работает — это самые подлые проблемы.
·>Что если потом внезапно окажется, что task1 — очень срочно надо, протестировано, требуется релизить, а task2 — "не успевают доделать/протестировать" и вообще "стейкхолдеры что-то там перетасовали"?

Такие решения принимаются заблаговременно (я привел ниже ориентиры по нашим срокам релизов для наглядности).
Были конечно ситуации, когда фичу с пересечениями передвинули на след. релиз, и были применены feature toggles. Но так получилось из-за "экономии" на ветках (source control был не на Git).

m>> Т.е. при merge в develop (а потом в release) каких-то существенных конфликтов быть не должно.
·>Проблема в том, что мерж веток A,B,C может работать очень по-другому, с разными конфликтами чем B,C,A — и это нетривиально понимать как всё работает.
m>> .>И никак не обеспечить, что порядок мержа 90 веток в девелоп будет ровно таким же как в релиз. А значит у тебя есть 90! вариантов как может выглядеть релизная ветка.

Конкретизирую: у нас обычно на релизный цикл (4-8 месяцев) порядка 10-15 бизнес-фичей. По коду (файлам) пересекаются максимум 2-3 фичи, логическое пересечения где-то в таком же объеме.
Есть ещё bugfix и support, он обычно попадает к QA на тестирование уже в release ветке (практически как в твоем workflow).
А также не-бизнес-фичи (всякий тех. долг, аудит кода и т.п.) без первоначальной привязки к релизу.
Кстати bugfix (на который ещё нет автотестов) вполне может проверяться вручную для каждой релизной ветки отдельно. И это в общем-то неизбежно.

m>> Сравнение кода позволит выявить потенциальные ситуации, когда конфликты при merge в master(release) разрешены иным образом, чем при merge в develop.
·>Каким образом ты будешь сравнивать код? С учётом того, что как ты выразился выше, не всё может быть замержено. Дифы могут быть практически любого размера и сложности. Т.е. весь этот процесс нетривиальный, запутанный, легко пропустить ошибки. В отличие от того, чтобы тупо сравнить два commitId — это работает железно.

через git diff по подкаталогам.
Конкретизирую: у нас monorepo (плюс пара субмодулей под бинарники и т.д) продукта, который поставляется конечному пользователю в одном инсталляторе, но внутри содержить много независимых по пользовательскому функционалу решений, которые пересекаются только по некоторым общим библиотекам. Поэтому сравнивать весь репо бессмысленно.
Если какая-то фича была "выкинута", то разрешить конфликты вручную заново. Проблему потенциальных "логических" пересечений закрыть через автотесты.

m>> Вот пример использования git-rerere в flow, очень похожем на обсуждаемый: [url=https://drupalsun.com/katherinebailey/2013/03/05/pragmatic-guide-branch-feature-git-branching-strategy]A pragmatic guide to the Branch Per
·>Это 2013 год, для "project first switched from Subversion to Git" — наверное сгодится.

Ну они пишут, что попробовали сначала git-flow, но в итоге отказались о него

·>Флаги можно делать и compile-time, и build-time.

Это усложняет поддержку кода. При разработке новых фичей придется учитывать присутствие в коде этой отложенной (на неопределенный срок) фичи.

m>> А у QA может просто не быть свободного времени на тестирование корректной работы "переключателя".
·>Это какая-то вялая отмаза. Если код недостаточно тестируется, то он может быть недостаточно качественным. И тут неважно переключатель тут тестируется или что-то ещё.

Это работает, если более-менее понятно, что спрятанная за переключателем фича точно попадет в релиз и в какие сроки попадет.
Т.е. QA могут просчитать, что они потратят время на тестирование фичи сейчас, но сэкономят позднее.
Для экспериментальных фичей с неопределенным будущим это не годится.

m>> Т.е. это не что иное, как Throw-away integration branch, описанный в документации по git.
·>Ну если почитать этот параграф повнимательнее, и ещё следующий "Branch management for a release", то можно заметить, Throw-away branch больше для демок и экспериментов, чем часть release-пайплайна. Т.е. основная разработка и тестирование всё равно ведётся отдельно в и в релиз уходит таг, т.е. то за что я топлю. По твоей же схеме QA происходит только в Throw-away branch, потом всё перезаливается второй раз (удваивая усилия на мержы-конфликты) в другой бранч и тут же объявляется релизом, без QA. То что результат мержа не тестируется — меня удивляет больше всего. А если перетестируете всё, то это удваивает нагрузку и на QA, а потом совершенно неожиданно: "у QA может просто не быть свободного времени".

QA пишут интеграционные автотесты. Они прогоняются на каждом build`е, в т.ч. после merge. Вручную результат merge не проверяется.

·>Это вообще неясно как организовать надёжно.
·>Как и в каких единицах измерить "существенность пересечения"?
·>Как детектить неявные пересечения? Даже изменения в разных файлах могут давать логические пересечения — конфликта vcs нет, а код не работает — это самые подлые проблемы.
·>Что если потом внезапно окажется, что task1 — очень срочно надо, протестировано, требуется релизить, а task2 — "не успевают доделать/протестировать" и вообще "стейкхолдеры что-то там перетасовали"?

Такие решения принимаются заблаговременно (я привел ниже ориентиры по нашим срокам релизов для наглядности).
Были конечно ситуации, когда фичу с пересечениями передвинули на след. релиз, и были применены feature toggles. Но так получилось из-за "экономии" на ветках (source control был не на Git).

m>> Т.е. при merge в develop (а потом в release) каких-то существенных конфликтов быть не должно.
·>Проблема в том, что мерж веток A,B,C может работать очень по-другому, с разными конфликтами чем B,C,A — и это нетривиально понимать как всё работает.
m>> .>И никак не обеспечить, что порядок мержа 90 веток в девелоп будет ровно таким же как в релиз. А значит у тебя есть 90! вариантов как может выглядеть релизная ветка.

Конкретизирую: у нас обычно на релизный цикл (4-8 месяцев) порядка 10-15 бизнес-фичей. В конфликтах по коду (файлам) участвуют максимум 2-3 фичи (на конфликт), логическое пересечения где-то в таком же объеме.
Есть ещё bugfix и support, он обычно попадает к QA на тестирование уже в release ветке (практически как в твоем workflow).
А также не-бизнес-фичи (всякий тех. долг, аудит кода и т.п.) без первоначальной привязки к релизу.
Кстати bugfix (на который ещё нет автотестов) вполне может проверяться вручную для каждой релизной ветки отдельно. И это в общем-то неизбежно.

m>> Сравнение кода позволит выявить потенциальные ситуации, когда конфликты при merge в master(release) разрешены иным образом, чем при merge в develop.
·>Каким образом ты будешь сравнивать код? С учётом того, что как ты выразился выше, не всё может быть замержено. Дифы могут быть практически любого размера и сложности. Т.е. весь этот процесс нетривиальный, запутанный, легко пропустить ошибки. В отличие от того, чтобы тупо сравнить два commitId — это работает железно.

через git diff по подкаталогам.
Конкретизирую: у нас monorepo (плюс пара субмодулей под бинарники и т.д) продукта, который поставляется конечному пользователю в одном инсталляторе, но внутри содержить много независимых по пользовательскому функционалу решений, которые пересекаются только по некоторым общим библиотекам. Поэтому сравнивать весь репо бессмысленно.
Если какая-то фича была "выкинута", то разрешить конфликты вручную заново. Проблему потенциальных "логических" пересечений закрыть через автотесты.

m>> Вот пример использования git-rerere в flow, очень похожем на обсуждаемый: [url=https://drupalsun.com/katherinebailey/2013/03/05/pragmatic-guide-branch-feature-git-branching-strategy]A pragmatic guide to the Branch Per
·>Это 2013 год, для "project first switched from Subversion to Git" — наверное сгодится.

Ну они пишут, что попробовали сначала git-flow, но в итоге отказались о него