Правильный git поток с веткой тестирования

Question

Я борюсь с созданием правильного git потока, и мне интересно, не могли бы вы помочь мне. У нас есть 3 разработчика и требования:

• мы используем GitLab
• нам нужна ветка, в которой разработчики объединяют запросы, где происходит проверка кода
• нам нужно есть ветка, в которой разработчики могут сделать что угодно для тестирования без проверки кода (эта ветка является источником для создания среды TST в OpenShift)

Текущее решение немного сложнее, и я не уверен, что git предполагалось использовать таким образом. Например, developer1 всегда вытягивает ветку "Develop" в свою локальную "dev1", при необходимости он может выполнить команду pu sh, чтобы "протестировать" ветку, где автоматическая сборка c происходит в среде TST. Как только разработчик уверен, что он работает, он может сделать sh изменения в своей удаленной ветке «dev1» и объединить ее, чтобы «разработать» там, где происходит проверка кода. Вот как это выглядит:

У вас есть идея, как это настроить?

Answer 1

Например, developer1 всегда вытягивает ветвь «разработка» к своему локальному «dev1».

Это проблема: долгоживущие ветки для разработчика. Это подразумевает владение кодом в ветке, а также смешивание множества различных функций и исправлений ошибок. Git Поток не должен их иметь. Удалите ветки для разработчиков из вашего рабочего процесса. Разработчики могут иметь их, если захотят, но они не являются частью обычного процесса.

Вместо этого используйте одну недолговечную ветвь для каждой функции. "Особенные ветви" . Они используются для одной и только одной функции. Это может быть отдельная проблема или задача, которая предоставляет простую схему именования: issue/#1234 - это ветвь для проблемы 1234. Когда функция завершена, они объединяются и удаляются. Ветвь fre sh открывается для следующей функции.

Ветви объектов вписываются в Gitflow , они являются ответвлениями develop.

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

Функциональная ветвь, выдвинутая и превращенная в запрос на слияние. pu sh что угодно для тестирования без проверки кода (эта ветвь является источником для создания среды TST в OpenShift)

ветвь функций, отправленная и используемая в качестве источника для вашей среды TST.

Answer 2

Краткий ответ:

Разветвление от мастера и создание ветки под названием "Интеграция". Разработчики также разветвляются от мастера, но пу sh в "Интеграцию". Тестируйте «Интеграцию» (или проверку кода) весь день, всю неделю, весь месяц, как только вы будете удовлетворены, включите его в «мастер». На этом этапе разработчики могут (захотят) перебазировать свои ветви с помощью master или удалить свои ветви (завершено создание функции) и создать новую ветку на основе (нового обновленного) master.

Таким образом, master всегда готов к отправке, так как 1) Он всегда стабилен (никакие разработчики не вставляют в него половину испеченного не просмотренного кода), а 2) все время тестируется (из «Интеграции»).