Обработка ветвления git для тестирования и производства

Эта проблема (ветвь разработки, загрязненная ветвями «неутвержденных, но уже интегрированных» функций) в точности описывает Раман Гупта в" Как создатели Git выполняют ветвление ".
(Репозиторий GitHub для этого рабочего процесса: _ 1_)

В вашем случае (gitflow) вам нужно будет отменить фиксацию слияния неутвержденных функций перед объединением разработчика в выпуск.

Но gitworkflow использует эфемерные ветки в противовес gitflow:

GitFlow выступает за наличие двух вечных ветвей - master и develop.

Оба рабочих процесса (gitflow или gitworkflow) используют ветки «функция» или «тема»:

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

Тема в конечном итоге объединяется с веткой "next" в gitworkflow.
Однако ключевым отличием является то, что ветка next никогда не объединяется с master (в отличие от вечной ветки "develop", которая предназначена для объединения с master / release в gitflow)

Теперь, когда topic перешел на next, он может быть частью бета-версии или приемочной версии. Таким образом, каждая следующая тема теперь может пройти второй этап стабилизации, что и является целью среды бета-выпуска / приемочного тестирования.

Однако обратите внимание, что с gitworkflow мы все еще не взяли на себя обязательство (без каламбура!) Включить этот topic в нашу следующую производственную версию - он все еще не был объединен с master.
Это похоже на концепция ветки GitFlow release, но гораздо более гибкая и мощная, поскольку master не имеет каких-либо зависимостей от next, а также next никогда не объединяется оптом с master (в отличие от соответствующих веток GitFlow develop и release).

Если следующий не объединен в master, как вы переводите функцию в рабочую среду?

После того, как тема признана достаточно стабильной для выпуска, она снова завершается и объединяется с master (или, возможно, с maint), снова с --no-ff, чтобы сохранить полную историю ветки темы.

Почему так лучше:

Обратите внимание, что в gitworkflow нестабильная и стабильная разработка никогда не смешивается в одной ветке.

Напротив, с GitFlow у меня есть два варианта:

1. Я могу протестировать свою тему изолированно в отдельной ветке, или
2. Могу слить в разработку для тестирования.

Ни один из вариантов не является привлекательным.

• Первый не предлагает истинной проверки стабильности темы при развертывании вместе с другой текущей работой, и
• последний обязывает тему развиваться, возможно, прежде, чем она станет стабильной.

Имея в виду:

Короче говоря, в GitFlow всегда есть неразрешимое противоречие между желанием сохранить чистоту и изолированность работы по разработке в тематической ветке и интеграцией тематических веток с другой работой путем их объединения для разработки, чтобы сделать их видимыми и тестируемый и для проверки на конфликты.
Gitworkflow позволяет достичь обеих целей, не жертвуя одной ради другой.

Я думаю, что правильный путь здесь:

• производство (...)
• мастер (ветвь разработки)
• особенность123
• особенность234
• особенность345
• особенность [номер]

Если можете, предоставьте клиентам домен feature [номер] .example.com. Таким образом, вы можете показать все функции перед слиянием в главной ветке. Если функция отклонена, она никогда не должна быть объединена в мастере. Если функция принята, ее необходимо объединить.

Хорошей альтернативой также является «промежуточный» домен, где можно развернуть код, когда это необходимо. Предположим, вашему клиенту нужно увидеть feature42, ... просто разверните feature42 в customer.example.com домене.

Где разработать новую функцию?

feature[number] branch

Где показать новую функцию?

feature[number].example.com

Где увидеть следующий спринт-код (мастер) в действии?

next.example.com

or

master.example.com

Где посмотреть производственный код?

www.example.com