Стратегия ветвления - для многократного выпуска с gihub

Question

Я работаю над проектом, в котором в настоящее время у нас есть следующие три фиксированные ветви

Develop - The code is deployed to development environment. It's a base branch for anyone who want to add new feature. 
Release - Deployed in QA environment, And QA can start testing on.  
Master -  Deployed to Production environment and available to clients. 

И у нас есть еще две динамические ветви: функция и исправление.

1. Любой, кто хочет начать новую разработку или исправление ошибки, разветвляет новую feature из ветви develop, а затем создает запрос на извлечение.

2. когда разработка завершена, она тестируется в среде разработки из ветви разработки, а затем создает запрос на слияние для release branch

3. QA развертывает ветку release в тестовой среде и запускает тестирование после завершения тестирования. он объединен с мастером, а затем развернут в производство.

Это все хорошо работает для большей части. Тем не менее, у него есть следующая проблема

Не все функции в QA (ветке релиза) протестированы и готовы к развертыванию (слияние с мастером) в конце выпуска. И поэтому мы не уверены, как создать пулл-запрос, так как он выберет все коммиты.

Я думаю, Github releases может быть решением для этого. Я могу создать новый выпуск, с которым когда-либо будет готова для развертывания функция, а затем объединить эти выпуски с главной веткой.

Однако, что я не уверен, так это когда развертывать в производство, из выпусков или из master?

Answer 1

Вы должны следовать стандарту Git Flow :

Вместо объединения какой-либо функциив ветку release (от develop) после тестирования вам нужно будет использовать «сокращение выпуска».Это выделенный момент времени, когда вы решаете, что хотите сделать релиз.Функции, которые планируется включить в этот выпуск, оцениваются и тестируются, и выпуск подтверждается.

Вам понадобится tag вашими выпусками ипри желании включить любые активы, которые связаны с этим выпуском для дальнейшего использования.Если это мобильное приложение, это отличное место для добавления .apk или .ipa.После того, как сокращение выпуска было сделано и помечено, вы захотите выпустить ветку release в производство .Как только это будет развернуто в производство, вы захотите объединить release с master и develop.

. При таком подходе каждая feature ветвьзакончится в develop, затем release (с соответствующим tag), затем master.Если функция все еще выполняется, когда сделано сокращение выпуска, оно просто не делает сокращение!Он будет добавлен в следующий релиз.Это даст ему достаточно времени для тестирования, прежде чем оно приблизится к release, не говоря уже о master.В связи с этим, master должно быть простым представлением вашего последнего известного «хорошего состояния» - точки, в которой вы были рады сообщить общественности.

Также обратите внимание, что hotfixes иbugfixes - это две разные вещи, и ни не должны переходить от develop.Исправления должны быть внесены в саму ветку release, а hotfixes должен быть создан из master и объединен в оба master и develop.