Gitflow и случайное слияние других функций

Недавно мы начали внедрять gitflow, следуя в основном некоторым видеороликам на YouTube и некоторым онлайн-статьям, а также функциям графического интерфейса в SourceTree.

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

developer 1 работает над feature 1, developer 2 работает над feature 2, ветка develop предназначена для разработки и находится в стадии подготовки, ветка master работает/работает

разработчик 1

  1. develop = master (синхронно с master)
  2. разработка -> переход к функции-1
  3. разработать ‹- объединено в функцию-1

разработчик 2

  1. develop != master (не синхронизирован с master)
  2. разработка -> функция ответвления-2
  3. разработать ‹- объединить функцию-2

Теперь мы подошли к проблеме, если developer 2 хочет оживить feature 2, объединив его с master, он будет содержать feature 1, то есть они оба будут жить.

Итак, мы явно делаем что-то не так - и это то, что нам нужно разъяснить, единственные 2 способа, которыми я могу видеть это с макушки головы, это

  • Вы создаете новые функции из master, а не из develop
  • Вы используете «Вишневый выбор», который принимает только фактически измененные файлы в master

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

Спасибо


git git-flow branching-and-merging feature-branch
person Owen    schedule 17.08.2016    source источник
comment
Что такое develop? Филиал? То, как сейчас поставлен ваш вопрос, неясно, почему вы думаете, что разработчик 2, объединяющий feature 2, также будет содержать feature 1.   -  person AnoE    schedule 17.08.2016
comment
да, это ветвь - она ​​будет содержать функцию 1, потому что разработчик 1 объединил функцию 1 с разработкой, вскоре после того, как разработчик 2 отделился от разработки для своей функции 2 - функция 1 была объединена с разработкой, поскольку она была готова для UAT от клиента   -  person Owen    schedule 17.08.2016
comment
Почему вы не хотите, чтобы функция 1 была запущена (вместе с функцией 2)? Когда разработчик 1 объединил функцию 1 обратно в разработку, она должна была быть готова к работе.   -  person vikingsteve    schedule 18.08.2016
comment
это может быть готово к производству, но это не означает, что клиент одобрил его запуск   -  person Owen    schedule 18.08.2016

Ответы (2)


arrow_upward
1
arrow_downward

Что ж, согласно документации gitflow http://nvie.com/posts/a-successful-git-branching-model/ :

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

Таким образом, разработчик 1 не должен объединять feature 1 в develop, пока это не будет гарантировано на 100% в следующем выпуске. И если это так, то для разработчика 2 нет проблем, чтобы от него отделиться, включая feature 1. Когда feature 1 находится в develop, то его следует считать "сделанным", за исключением багфиксов, его не так-то просто удалить из develop.

Тем не менее, я нахожу gitflow громоздким и предпочитаю http://dymitruk.com/blog/2012/02/05/branch-per-feature/ себя. Помимо того, что он структурно намного чище, он имеет огромное преимущество, заключающееся в том, что тривиально легко отказаться от функций из «следующей версии» в любой момент, и что «проблема», с которой вы столкнулись (одна функция неявно влечет за собой другую) не может возникнуть .

person AnoE    schedule 17.08.2016
comment
Спасибо за отзыв - однако проблема, о которой я упоминаю, говорит о том, что циклов выпуска нет, поэтому вышеупомянутый способ gitflow не работает из-за исходной проблемы. - person Owen; 18.08.2016
comment
Оба рабочих процесса не заботятся о том, есть ли у вас длинные запланированные циклы или специальные выпуски... - person AnoE; 18.08.2016

arrow_upward
1
arrow_downward

Когда разработчик 1 объединил функцию 1 обратно в разработку, она должна была быть готова к работе.

Поэтому не должно быть проблем с выпуском функции 2 и функции 1 вместе.

Но у вас есть несколько вариантов здесь.

  1. Пока не заканчивайте функцию 1 (если она еще не готова к производству, не объединяйте ее обратно в develop).
  2. Выпускайте чаще (сначала выпускайте фичу 1, как только она будет закончена).
  3. Используйте переключение функций (имейте свойство feature1.enabled=false) и выпустите функцию 1 вместе с функцией 2, хотя эта функция отключена.

Помните, что в git flow релизы всегда делаются из ветки develop, поэтому в идеале вы должны иметь возможность делать релиз из develop с готовым к производству кодом практически в любое время.

person vikingsteve    schedule 18.08.2016
comment
Привет - та же проблема, что и в приведенном выше предложении - проблема в том, что нет циклов выпуска - когда клиент хочет, чтобы эта функция была запущена, она запускается. - person Owen; 18.08.2016
comment
См. пункт 1: если он не готов к производству (или если клиент еще не хочет, чтобы функция работала), не объединяйте ее обратно в develop, или пункт 3: переключение функций. - person vikingsteve; 18.08.2016