Как избавиться от развивающейся ветки для упрощенного Git-потока

В постоянно развивающемся веб-проекте (а не в продукте) в настоящее время у нас есть следующая стратегия ветвления, примерно основанная на потоке git :

• разработка ветки: последняя рабочая версия
• основная ветка: версия будет выпущена / выпущенная версия
• тематические ветки: особенности в разработке
• ветви исправлений: срочные исправления в выпущенной версии

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

Ветви объектов создаются на основе разработки или последнего коммита, который был объединен с основным. Построен запрос на извлечение из ветви функций для разработки, развернутой в бесплатной тестовой системе, где выполняются интеграционные и приемочные тесты (автоматические и ручные). После успешного тестирования и проверки PR объединяется, и он становится частью следующего выпуска (т. Е. Объединяется с разработки в мастер).

Моя цель

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

У меня есть следующие ограничения:

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

Где я не уверен насчет перехода:

• В настоящее время я создаю запросы на запуск для тестирования и слияния коммитов для релизов. Могу ли я объединить это?
• как бороться с исправлениями, когда мастер опережает последнюю версию. Должен ли я создавать и развертывать релизы непосредственно из ветвей исправлений?
• Есть ли разумный способ работы с функциями, которые следует исключить из выпуска после того, как они уже были объединены? Является ли отдельная ветвь разработки действительно преимуществом для этих случаев? Большую часть времени я в любом случае возвращаю и возвращаю коммиты вручную.

ИМХА проблема вы столкнулись лишь побочный эффект плохой стратегии ветвления вы начали: вы эффективны вспашку нового развития на develop(то есть то , что сходится по направлению к будущей коде производства) через в текущем производстве коды на master. Это приводит к противоречивым требованиям и проблемам, так как обычно будущий код отличается от текущего:

• новое развитие дестабилизирует производство - регрессия, наблюдаемая после слияния developсmaster
• Стабилизация производства замедляет будущее развитие - вам нужно стабилизировать, developчтобы сделать его достаточно хорошим для объединения вmaster

Отбрасывание developне поможет (сильно) - вы не устраняете проблему, вы просто переносите developспецифическую часть проблемы в master.

Лучшим подходом было бы перенести производство за пределы текущей / будущей разработки, чтобы предотвратить вмешательство в разработку для будущих выпусков, как показано на этом рисунке из раздела «Что такое модель ветвления»? :

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

Как это будет работать для вас:

• в developветви пропадает, как вы хотели, впитывается вmaster
• masterветвь ваш ствол, это где развитие происходит без каких - либо ограничений скорости (она никогда и не сливалась в производство).
• производство - это одна или несколько releaseветок, извлеченных из masterметки / метки, которые считаются достаточно близкими к качеству продукции (в случае необходимости можно обратиться к краткому списку оставшихся задач, которые можно выполнить в этой ветке). Эти ветви могут получать только прямые исправления и / или исправления, выбранные из вишни master, они никогда не объединяются masterили другие ветви
• Исправления - это прямые коммиты в releaseветки

Если исправление применяется только к производственной версии, но не к исправлению, masterоно напрямую передается в releaseветку. Если это относится и к обоим, то, как правило, оно относится к masterпервому, а также к черри и к двойному release.

Теперь, глядя на то, что входит в master(который находится за точкой, где текущая releaseветвь снята), у вас есть 2 варианта:

• продолжайте с функциональными ветками, как вы делаете сегодня, за исключением того, что они будут основаны master, а не develop. Преобразование их в оперативные исправления остается возможным - вам просто нужно перенести их в соответствующую releaseветку вместоmaster
• переключиться на непрерывную интеграцию и воспользоваться ее преимуществами (это можно сделать в любое время в будущем), в том числе в прогрессивном режиме - постепенно вытягивать все меньше и больше ветвей функций.

Если вам нравится этот подход, вот как вы попали туда, где вы находитесь сегодня:

• установить стратегию именования релизов:
  • у вас не может быть текущей ветки релиза с тем же именем
  • вы не можете (не должны) перебазировать или синхронизировать ветку выпуска
• немедленно вытяните releaseXветку master, следуя этой стратегии именования
• Остановите коммиты от входа develop, они скоро пойдут прямо к master.
• слиться developсmaster
• поручить разработчикам перебазировать свои рабочие пространства masterвместо develop.
• открыт masterдля коммитов
• удалить, developесли вы хотите (или оставить его постоянно заблокированным / только для чтения для справки)

Допустим, вы удалили основную ветку (вы можете переименовать Develop в Master, чтобы сбить с толку вашу команду, если захотите позже) и просто использовать теги для выпусков в ветвях разработки или исправлений. Вы вынули ветку, но разница в изменении синтаксиса. Смена ради перемен.

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

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

Вы уже строите и тестируете код для каждой из ветвей pull-request и hot-fix. Это означает, что в совокупности сумма всех ответвлений, ожидающих по запросу-запросу, является вашей виртуальной developветвью.

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

Когда вы создаете релиз из master, вы обычно создаете тег для этого релиза. Более поздние исправления могут использовать этот тег для создания новой ветви исправлений, из которой будет осуществляться развертывание, даже если край masterуже впереди. В этой ветке исправлений вы, вероятно, также пометите второстепенный выпуск и убедитесь, что изменения были объединены master.

Удаление объединенных функций из релиза довольно сложно сделать с помощью git. Лучший механизм для этого - использовать git revertкоммит слияния. Но это делает почти невозможным вернуть эти особенности / изменения, и история становится запутанной.

Намного лучшим способом обработки разделения для развертывания кода и выпуска функций являются флаги функций . Если ваши разработчики могут скрывать свои функции за некоторыми условиями в самом коде, вы можете развернуть их код, но отключите эту функцию. Это отдельная тема, но существует много информации об этом (включая вопросы и ответы на devops.SE).

Хорошо @ dan-cornilescu говорит, что это хорошо для вашей конкретной проблемы, но более общий случай для разработки на основе соединительных линий (упомянутый в Непрерывной доставке, Lean Enterprise и Руководстве по DevOps) приведен здесь: https://trunkbaseddevelopment.com/