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