Как мне справиться с фиксацией нескольких веток во время разработки?

Question

Я ищу современные знания / лучшие практики / советы.

Мы рассматриваем возможность перехода к моно-репо для нашего развития. Мы используем Scrum с Рассказами / Эпиками / Спринтами (я не полностью обновлен по всей терминологии ... Я стар, и некоторые новые вещи кажутся ПРОСТО такими же, как старые ... просто с другими именами).

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

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

То, что нам хотелось бы, - это иметь возможность «проверять» текущую функциональную ветвь кода (я использую терминологию git, просто как это то, что мы используем в настоящее время), позволяя разработчику выполнять их кодирование , запускайте тесты локально и, если вас устраивает, вносите конкретные изменения в разные ветви. Так, например, изменения миграции идут в ветку задачи миграции, изменения моделирования / сопоставления API переходят в ветку соответствующей задачи и т. Д.

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

Достигать чего-либо подобного с помощью git крайне сложно.

Для нас ветвь функций предназначена для истории (т. Е. Клиент хочет иметь возможность предоставить своим клиентам возможность изменять забронированное время сеанса, предполагая наличие доступности, выплачивая возврат или запрашивая дальнейший платеж, если требуется). Для достижения этой цели существуют различные задачи, которые необходимо выполнить (новые данные, работа с UI / UX, работа с API и т. Д.). Каждый из них - определенные задачи для истории. У каждого своя ветвь, которая.

Есть ли лучшие варианты?

Если нет, есть ли лучшие практики, которые кто-нибудь может порекомендовать?

Answer 1

Возможно, вы ищете gitflow (для git) или hgflow для Mercurial.

Это ветвящиеся рабочие процессы, которые, кажется, предназначены для решения проблемы организации, котораяВы позировали.

---

gitflow:

Создано / защищено Винсентом Дриссеном .Хотя эта модель была создана с учетом git, по большей части она не является специфической для git.

Центральный репо содержит две основные ветви с бесконечным временем жизни:

masterdevelop

Мы считаем master основной ветвью, в которой исходный код HEAD всегда отражает состояние готовности к работе.

Мы считаем development основной ветвью, которая отражает состояние с последней версией.доставлены изменения развития.Некоторые называют это «интеграционной ветвью».

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

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

Различные типы веток, которые мы можем использовать:

Ветви функций Ветви релизов Ветви исправлений

Каждая из этих веток имеет определенное назначение и связана со строгими правилами..

( Источник текста )

---

hgflow:

Это ртутный эквивалент gitflow.

hgflow - это расширение с открытым исходным кодом для Hg, вдохновленное git-flow и построенное на популярной модели ветвления Винсента Дриссена.По сути, он формализует рабочий процесс вокруг модели Дриссена и предоставляет команды для ветвления и объединения функций, выпусков и исправлений в этой модели.

...

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

hgflow home page .

( textsource )

---

Кроме того, если вы еще не посмотрели, как такой сайт, как github , позволяет управлять функциями с такими вещами, как pullзапросы, которые могут быть полезны для размышления.Насколько я понимаю, github предоставляет инструменты, которые помогают задействовать / управлять рабочими процессами, такими как модель ветвления Дриесена.