Рабочий процесс для обработки запросов на вытягивание в рабочем процессе gitflow (с нечастыми выпусками)?

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

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

Проблема в том, что когда в релизе X возникают конфликты между новой функцией и другими функциями, как разработчик их исправляет? Выполнение слияния в самом github неприемлемо, слияние releaseX с веткой функций также неприемлемо (это приведет к включению несвязанных функций и затруднит выпуск функции в конце концов).

В итоге мы создали ветку только для слияния, что-то вроде разрешения/релизаX_my_beautiful_feature.

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

Ребята, какой рабочий процесс вы используете при использовании как запросов на включение, так и релизов?


person scc    schedule 04.04.2017    source источник
comment
Основная идея git-flow для исправлений релизов — это отдельная ветка исправлений, в которой вы исправляете определенные ошибки и создаете новый релиз после их исправления. Так что для меня это звучит так, как будто вы этого не делаете, и поэтому у вас есть эти концептуальные проблемы. Поправьте меня, пожалуйста, если я ошибаюсь.   -  person ckruczek    schedule 04.04.2017
comment
У нас есть ветка релиза, в нее объединяются функции и исправления, которые входят в новый релиз. Проблема в том, что когда возникают конфликты ‹i›и‹/i›, мы используем запросы на вытягивание, единственный способ для разработчика исправить эти конфликты без слияния функциональной ветки с релизной веткой, т.е. Функция запроса на вытягивание и без слияния ветки релиза с веткой функциональности заключается в том, чтобы разработчик создал конкретную ветвь из ветки функциональности, объединил ветку релиза и устранил конфликты.   -  person scc    schedule 04.04.2017
comment
На сайте Atlassian есть интересное описание того, как рабочий процесс можно поддерживать с помощью рабочего процесса gitflow. Пожалуйста, посмотрите и дайте нам знать, если вы найдете это полезным или нет.   -  person ckruczek    schedule 05.04.2017


Ответы (1)


Как сказал @ckrusek, у Atlasssian есть хороший документ о различных виды рабочих процессов. Что касается рабочего процесса запросов gitflow + pull, они рекомендуют:

  • особенности ответвления развиваются
  • фичи делают pull-request для разработки
  • релизы ответвляются от разработки (соглашение об именах ветвей: релиз-* или релиз/*). Ветка релиза служит только для подготовки релиза, любая функциональность, которая еще не находится в разработке, откладывается до следующего цикла релиза.
  • объединить ветку релиза с мастером и разработать
  • ветви обслуживания/исправлений ответвляются от главного
  • ветки обслуживания/исправлений сливаются в основную и развиваются

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

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

person scc    schedule 05.04.2017