Стратегия ветвления Git для новой стройной команды

Question

У нас есть веб-приложение, для которого у нас есть несколько корпоративных клиентов. Недавно мы решили предложить его в качестве приложения SaaS и придерживаться бережливого подхода (параллельно с нашим корпоративным предложением). Это означает, что у нас есть эксперименты на ходу, которые могут не попасть в производство.

Прежде чем мы стали худыми, мы были довольны следующей стратегией ветвления (я считаю, что она довольно стандартна):

• мастер - всегда стабильный
• dev - часто нестабильный (ветки функций обрезают dev для новых функций, которые войдут в следующий основной выпуск)
• major_release_x - live (отключение master после слияния dev с master, здесь исправления ошибок и слияние обратно с master и dev)

Теперь у нас есть следующее в дополнение к вышесказанному, и это не очень хорошо работает:

• lean_release_branch - жить (отрезать major_release_x и содержит эксперименты)
• эксперимент_x - обрезать major_release_x (здесь мы взламываем эту функцию вместе, а затем объединяем ее в lean_release_branch)

Наш сценарий сейчас заключается в том, что нам нужно выпускать быстро и часто, как того требует подход lean, и когда мы получаем твердую обратную связь по поводу чего-то произвольного, нам нужно произвести его и выпустить как можно скорее (за исключением lean_release_branch).

Проблема в том, что мы не можем создать функциональную ветку из dev (так как она, скорее всего, нестабильна), и мы не можем создать функциональную ветку из lean_release_branch по двум причинам:

1. он был загрязнен экспериментальным кодом, так что это изменение / функция не сможет вернуться к мастеру
2. lean_release_branch всегда должен быть готов к выпуску, поэтому мы не можем быть заняты тестированием и исправлениями в нем (после объединения изменений / функций в него), если есть критическая проблема, которую необходимо исправить и выпустить

Кто-нибудь знает лучшую стратегию для нашей установки?

Answer 1

Помимо упоминаний GitFlow Nozari, есть также GitHub Flow. Место, в котором я работаю, использовалось в качестве основы (мастер всегда стабилен, развивается в функциональных ветках, извлекает запрос с проверкой перед слиянием). Мы внедряем реже, чем GitHub, поэтому на мастер-уровне мы используем аннотированные теги для отслеживания выпусков, а облегченные теги указывают на то, какой коммит сейчас находится в стадии подготовки / производства. Этим управляет самоцвет Ruby https://github.com/mydrive/capistrano-deploytags.

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

Answer 2

Я только что изменил с TFS на GIT, и модель, которой я следую, основана на этом посте.

Что касается ваших экспериментов, то это просто "избранные ветви", которые не вернутся к развитию (слились в развитие).

Answer 3

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

Таким образом, новые производственные функции будут доступны в вашем выпуске Lean и будут в следующем основном выпуске, и филиал Lean никогда не нужно объединять снова.

Дальнейшие отзывы клиентов об этой функции могут быть реализованы в production_feature_y и снова объединены с dev и lean_release_branch.

Исправления ошибок могут быть обработаны таким же образом, сделаны на ветви от major_release_x и объединены в major_release_x и lean_release_branch.