ревью сложных фич

merge request'ы сложной фичи часто смотрятся и подтверждаются в порядке создания(так удобнее вникать) 0,1,2...

Лучше вливать ветки в dev по порядку от самой первой и у следующих менять targer branch на dev.

Не обязательно ждать пока не будет закончено ревью последей ветки фичи, чтобы влить их каскадом друг в друга. При долгом ожидании могут возникнуть конфликты в первых ветках, разрешение которых придётся вливать в следующие. И в истории влитых merge request'ов будут такие же изменения которые и смотрелись, а при вливании каскадом у ветки feature/feature0 будут изменение всей большой фичи.

Нужно обсудить когда использовать BUG/FIXES и в каком коммите работы над фичей ставить CLOSES

Обсудить как будем работать с feature флагами

bugfix - можно покороче fix

feature/new_feature_name0

как вариант, можно называть по номеру задачи task/12345. Не всегда можно придумать короткое название. И так сразу видно к какой задаче относится. При добавлении новой ветки тут же создавать merge request со статусом WIP, в заголовке указывать заголовок из задачи. На странице merge request можно видеть какие на данный момент ведуться работы над проектом.

1. Для идеальных случаев именуем ветку просто dev
2. Можно в заголовках давать контекст где вносились изменения(в каком функционали)

Как быть с МП, в которых есть несколько версий в разработке - а-ля BlueOrange? что если бизнес требует один набор фич делать с версией 2.x, а другой - 3.x

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

Нужно где-то описать версионирование - или это решение в рамках проекта?

Версионирование стандартное 1.1.1

Как происходит Accept MR?

По ревью решили что заливает ревьювер

Нужна статья в wiki про trunk-based разработку и ссылка на неё

Просто достаточно ссылаться на сайт про trunk-based

Можно решить проблемы автоматизации сбора ченджлога если добавить к тегу CHANGELOG версию. Можно попробовать решить её спомощью фильтрации коммитов по парент коммитам и веткам. Но нужно у qa и менеджеров уточнить как лучше делать ченджлог.

Как быть с МП, в которых есть несколько версий в разработке - а-ля BlueOrange? что если бизнес требует один набор фич делать с версией 2.x, а другой - 3.x

Может разделять их по разным проектам в gitlab?