Подумалось тут про сферического коня в базовом вакууме.

Вот допустим, у нас есть проект, где мы ведём разработку в бранчах: отделились от некоторого условного DEV, далее разработчик педалит изменения, затем это проходит цикл QA-активностей, затем либо слияние с DEV, либо откладываем в сторону на N времени (бизнес передумал/думает, разработчика потащили на более приоритетную задачу и т.п. — не суть)

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

Преположение: представим, что размер БД весьма крупный (и нужный для acceptance), и обычной локальной девелоперской пустышкой тут не отделаться (как минимум на QA-стадии)

Вопрос: как лучше управлять деплоями этих бранчей на QA-среду, если у тестера может быть разный порядок тестирования этих бранчей? Каждый раз начинать из некоторого эталонного бэкапа, на который затем уже накатываются разрушающие миграции? Или есть идеи поинтереснее?

Стек Java/MySQL, хотя вряд ли это столь существенно.