Почему релизную ветку отводят от деф ветки, а не от мастера
Что проверяют
Понимаете ли вы модель ветвления, внутри которой живёте как тестировщик: откуда взялась сборка на стенде, куда уйдёт фикс найденного дефекта и почему состав релиза в какой-то момент перестаёт меняться. Вопрос формально про git flow, но у QA его спрашивают ради процесса, а не ради терминов.
Как отвечать
В классическом git flow ветка master (или main) хранит только то, что уже уехало в прод: каждый её коммит это отмеченный тегом релиз. Вся новая работа накапливается в develop, туда вливаются ветки фич после ревью. Релиз это срез накопленного, значит и брать его надо оттуда, где оно накоплено. Ветка, отведённая от master, будет точной копией предыдущего выпуска: в ней нет ни одной новой задачи, тестировать и выпускать нечего.
Смысл отдельной ветки release/* в заморозке состава. С момента отведения команда продолжает мержить фичи в develop, а в релизную ветку принимаются только исправления дефектов, найденных на регрессе. Для тестировщика это главное: набор, проверенный вчера, не поменяется под вами сегодня. Когда регресс зелёный, ветка вливается в master с тегом и обратно в develop, чтобы правки не потерялись.
Отсюда практика: в баг-репорте указывать ветку и номер сборки, а исправление регрессионного дефекта просить именно в релизную ветку, иначе оно не доедет до выпуска. Исключение это hotfix: ветку для срочной правки прода отводят как раз от master, потому что чинить надо ровно то, что сейчас у пользователей, и вливают её потом в обе ветки.
Где спотыкаются
Отвечают «так принято» и не могут сказать, что сломается при отведении от мастера. Проверка тут простая: такая ветка равна прошлому релизу, новых изменений в ней нет.
Забывают про обратное вливание. Исправления, сделанные в релизной ветке и влитые только в master, теряются, и тот же дефект возвращается в следующем выпуске уже как регресс.
Путают эту модель с trunk based, где develop нет вовсе, а релиз собирается срезом с основной ветки и управляется флагами фич. Схема ветвления зависит от процесса команды, поэтому разумнее спросить, как устроено у них, чем пересказывать статью.