Мы используем Git Flow в нашем последнем проекте для iOS, и я пытаюсь выработать способ работы с QA, чтобы они могли протестировать последнюю версию, а также протестировать новую функцию, не беспокоясь о том, какие ошибки были исправлены в какая ветка.

В настоящее время они проходят тестирование наrelease/v1.0.1 ветка, в которой исправлено несколько ошибок из оригиналаrelease/v1.0, Параллельно я работал над новой функцией, которая была запланирована на выпуск v1.1, но была отделена отdevelop ветвь одновременно сrelease/v1.0.1 и поэтому не имеет ни одного исправления ошибки в нем.

Сегодня отдел контроля качества хотел бы взять мою новую функцию для тест-драйва. Однако, если я создам их сборку из моей ветки, ни одно из исправленных ошибок, которые они повторно тестировали и закрывали, не будет там. Поэтому я получу поток жалоб и паники по поводу ошибок, которые были вновь введены ... Чего я хочу избежать!

Итак, каков лучший способ заставить их проверить это? Я мог бы слитьrelease/v1.0.1 в мою ветку функций, но тогда я должен убедиться, что я не сливаюсь обратно вdevelop доrelease/v1.0.1 был выпущен ... И я думаю, в определенной степени, это нарушает методологию Git Flow. Я мог бы создать совершенно новую ветку только для тестирования качества, которая объединяет мою функцию сrelease/v1.0.1, но что мне делать с ошибками, обнаруженными в этой ветке? Куда мне слить его обратно после раунда QA?

Вдобавок ко всему этому, я должен рассмотреть номера сборки и номера версий, чтобы они имели смысл. В настоящее время номера версий используются для выпуска, а номера сборки увеличиваются с каждой новой сборкой для QA. Однако, если они получают сборки из двух отдельных ветвей, я мог бы столкнуться с конфликтами номеров сборок, которые могли бы вызвать путаницу.

Как лучше всего справиться с этими проблемами?