Поддерживать релизы / ветки в «гибком» ритме?

Новая ветка, такая как ('new_feature_branch'), предназначена для материализации усилия по развитию, которая несовместима с текущей веткой (например, 'release_branch')

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

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

По сути, все сводится к вашему определению рабочий процесс слияния.

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

Я бы предложил следующее, которое мы используем в моей текущей среде: относитесь к незапланированной функции, как к исправлению безопасности.

• Каждому запланированному выпуску (например, 3.0, 3.1) присваивается собственный номер версии и собственный тег в исходном коде. После того, как он выпущен, вы не трогаете его.
• Новые функции после запланированного выпуска переходят в следующий запланированный выпуск (например, 3.2).
• Если вам необходимо изменить выпущенную версию кода, это «незапланированный выпуск», и ему будет присвоен номер версии патча (например, 3.1.1, 3.1.2). Все изменения:
  • Внедриться в новой ветке на основе последнего патча для этого выпуска (например, 3.1.1 создается из 3.1.0, 3.1.2 создается из 3.1.1)
  • Немедленно объединяются в транк, поэтому они также попадают в следующий запланированный выпуск
• После реализации незапланированной функции вы превращаете ветку в тег (иначе говоря, не трогайте ее) и продолжаете работать в магистрали.

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

В моем офисе мы обычно работаем в 3 филиалах в любой момент времени.

• Выпуск: здесь тегируется и хранится код, который в настоящее время развернут. Если нам нужно исправить какие-либо критические ошибки, это то место, где мы работаем. При развертывании мы обычно увеличиваем исправление части тега (например, 1.19.0 -> 1.19.1).
• QA: Здесь помечается и хранится код, который готовится для клиентов. Эта ветвь используется, когда мы начинаем новую работу и у нас есть код, который в настоящее время тестируется QA при подготовке к следующей поставке.
• Main: Здесь делается вся новая работа.

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

С помощью описанной выше стратегии ветвления мы смогли внести основные изменения в функции с доставкой в ​​конце каждого спринта.

Не похоже, что вы действительно живете в среде Scrum. Scrum требует команда, которая должна быть ВЫПОЛНЕНА в конце каждого спринта, который должен длиться не более четырех недель (более вероятно, от одной до двух недель). Итак, каждые пару недель у вас в любом случае должна быть полностью протестированная, работающая и потенциально развертываемая система.

Единственный известный мне способ сделать это - иметь исчерпывающие, полностью автоматизированные наборы тестов как для заказчиков, так и для разработчиков (как предписывает Extreme Programming).

Я не уверен, зачем вам нужны ветки в этом случае, но я также не понимаю, почему они не поддерживаются. По моему опыту, чем короче ветка, тем лучше.