Ручка git разветвления для тестирования и производства

Question

Работая с git (flow) и имея среду стадии / тестирования, где клиент делает свои обзоры разработанных вещей, каков наилучший способ обработки функций, которые не одобрены вместе с функциями, которые есть?

Рассмотрим сценарий, когда несколько разработчиков работают с различными функциями в спринте или в непрерывном рабочем процессе. Функции должны быть проверены заказчиком, и для возможности их просмотра в рабочей среде они должны быть объединены с веткой dev и развернуты.

Если, скажем, две функции были разработаны, считаются выполненными командой разработчиков и переданы в dev. Клиент рассматривает их и утверждает ОДИН из них. Но теперь заказчик хочет выпустить одобренную функцию в производство. Ветвь dev теперь "загрязнена" неподтвержденным кодом функции, который нельзя отправить в производство.

Каков наилучший способ справиться с таким сценарием? Конечно, на самом деле все сложнее. Является ли вишня выбором решения или следует пересмотреть весь процесс и обработку веток?

Answer 1

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

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

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

Сторонники GitFlow, имеющие две вечные ветви - master а также develop

Оба рабочих процесса (gitflow или gitworkflow) используют ветки "feature" или "topic":

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

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

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

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

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

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

Почему это лучше:

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

В отличие от GitFlow, у меня есть два варианта:

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

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

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

Имея в виду:

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

Answer 2

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

• производство (...)
• мастер (ветка разработчика)
• feature123
• feature234
• feature345
• Функция [номер]

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

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

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

feature[number] branch

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

feature[number].example.com

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

next.example.com

или же

master.example.com

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

www.example.com