Я не уверен, правильно ли я понимаю описание вашей проблемы, поэтому я пытаюсь перефразировать ее:
- Вы используете какой-либо сервер непрерывной интеграции и развертывания.
- Ваш исходный код находится на GitLab.
- Пометка коммита в вашей ветке
develop запустит конвейер / сборку QA, которая собирает ваше приложение из этого коммита и развертывает его в пространстве QA.поэтому тестеры могут установить и протестировать его.
Теперь ваш вопрос выглядит следующим образом:
Должна ли команда разработчиков ждать («заморозка кода»)) с передачей в ветку develop, пока тестеры не закончат тестирование?
Если бы вы спросили, что я описал выше, мой ответ будет следующим:
Попробуйте применить рабочий процесс git в качестве модели git-ветвления в будущем.
Для вашей текущей проблемы просто создайте другую ветку из коммита, который вы пометилина вашей develop ветке и назовите бюстгальтерnch release.
Теперь разработчики могут продолжать работать над новыми функциями в обычном режиме и фиксировать свои изменения в своей ветке develop.
Если тестировщики обнаружат ошибки, которые необходимо исправитьВы можете сделать это в ветке release.Когда все исправлено, вы можете собрать протестированную версию приложения из ветки релиза.
Не забудьте объединить исправления ошибок, которые вы сделали в вашей ветке release, с веткой develop после окончания.
РЕДАКТИРОВАТЬ после прояснения вопроса:
Как я понимаю: Gitflow, при правильном применении, должен фактически решить именно ту проблему, о которой вы задаете вопрос 1:
Ветка, в которой работает ваш повседневный разработчикдобавлено в develop.Когда вы достигаете точки, когда вы реализовали все, что хотите, и думаете, что готовы что-то выпустить (с точки зрения разработчика), вы создаете ветку release, чтобы где-то сохранить текущую версию (ваш кандидат на выпуск), и позволить тестировщикампроверить эту версию.Вы, как разработчик, можете просто продолжать работу над следующими функциями и продолжать вносить изменения в ветку develop.
Когда тестеры находят ошибку, вы исправляете ошибку в ветке release.Когда все исправлено, вы можете создать версию приложения из ветки release и выпустить ее для клиентов.Когда он действительно выпущен, вы перемещаете ветку release в ветку master, а также объединяете свои изменения в ветке release обратно в develop.
Таким образом, ветвь релиза существует именно для того, чтобы избежатьпроблема 1) насколько я понимаю.Скорее всего, существует какая-то причина, по которой ваш процесс работает таким образом, но зачем создавать ветку release после , которую тестировали тестеры?