Преимущества использования ветвей git против нескольких репозиториев

Мы делаем разработку для кода автоматизации.

Наш код автоматизирует продукты компании и синхронизируется с определенной версией продукта.

В настоящее время у нас есть 1 большой репозиторий Git с несколькими ветвями в нем - v1.0, v1.1, v2.0 (автоматизация для версии 1.0 идет в ветке v1.0 и т.д.).

Каковы преимущества и недостатки их использования в одном репозитории с ветвями или с сохранением каждого кода версии в отдельном репозитории?

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

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

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

Ни один из этих звуков не похож на то, что мы сейчас делаем.

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

Ответы

Ответ 1

Несколько ветвей

Плюсы:

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

Минусы:

  • разбиение ветвей (вам нужно управлять/удалять сумму ветвей) Теги
  • относятся ко всем репо (а не только к "некоторым продуктам"

Несколько репозиций

Pros

  • вы можете вытащить из основного репо только то, что вам нужно, и работать оттуда.
  • вы можете легко очистить старые "ветки" (просто удалите это конкретное репо)

Против

  • дублирование репо (занимает больше места)
  • Управление репо (нужно указать правый пульт (ы))

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

Ответ 2

Здесь интересный ответ с использованием тегов и ветвей Git из этого вопроса: fooobar.com/questions/720/... (ответ None-da)

  • Создайте тег при достижении новой версии. (V3.0.0)

  • Создайте ветвь, когда вам нужно изменить ее в первый раз

    git checkout -b v3.0.0_branch v3.0.0

  • Примите участие в ветке и создайте новые теги при достижении v3.0.1, v3.0.2, v3.1.0

Ответ 3

Не так давно моя компания прошла аналогичную дискуссию (плюсы и минусы веток). При проведении исследований я нашел следующую инструкцию, чтобы быть полезной. http://guides.beanstalkapp.com/version-control/branching-best-practices.html Надеюсь, это поможет и вам.