Рабочий процесс Git с несколькими стабильными ветками, синхронизация с SVN - PullRequest
Новая
       56

Рабочий процесс Git с несколькими стабильными ветками, синхронизация с SVN

2 голосов
/ 05 марта 2012

Наш проект был преобразован из SVN в GIT.Разработчики сейчас используют git-svn, но хотели бы перейти к использованию большей мощности под капотом.Список пожеланий:

  • мощное ветвление, например ветки тем / компонентов
  • изоляция между основной и промежуточной работой над выпусками, иногда несколько параллельных.
  • худое и среднее и стабильноеНастройка Jenkins-CI - минимальное обслуживание (по сравнению с изменением конфигурации задания после каждого выпуска)
  • короткие итерации, выпуск команды разработчиков в QA каждые 2 недели;не обязательно за пределами
  • нескольких продуктов (P1..P3), созданных из одних и тех же источников, выпущенных независимо;с переменным давлением
  • имеют больше случайных, не git пользователей в "большей команде" ... они S & U :) .. но мы должны предоставить им доступ к SVN вминимум 1 ветка (ствол).Их вклад ограничен несколькими директорами, поэтому здесь нет большого риска конфликта.

Будет ли работать следующая стратегия?

  1. разработка: основная ветвь, где происходит развитие, a 'la git-flow
  2. стабильный продукт Отрасли: продукт1 .. продукт3.Один или несколько из них получат слияние с основной линии после выпуска dev.Похоже на 'запуск релиза 1.4.3' в потоке git, но это будут постоянные ветви.Релизы будут помечены здесь, а затем объединены для разработки.В этот момент он будет стабильным, как master в git-flow, только несколько из них.
  3. прекратите использовать git-svn напрямую - вместо этого добавьте / вытяните в зеркало.Также можно использовать ветви функций, если необходимо
  4. объединить svn / trunk -> development.Свн получал бы случайные и отдельные проверки;поэтому планируем автоматизировать его с помощью задания Дженкинса, уведомляя людей в случае сбоя, чтобы их можно было объединить вручную
  5. merge development-> svn / trunk: регулярно (например, ежедневно), в пакетном режиме.Это, вероятно, самая шаткая часть (по крайней мере, для новичков).Планировать что-то вроде rebase или какого-либо мастера сброса
  6. Настройка CI будет простой, например, test и dev строятся вне основной линии, официальный продукт строится из собственных веток продукта

Git-Flow заманчиво - в основном, так как оно хорошо описано и автоматизировано.Но это не похоже на идеальное совпадение для моего случая;главным образом из-за потенциально параллельных выпусков, нескольких линий продуктов и аспектов CI .

Буду признателен за любые обоснованные мнения.

1 Ответ

3 голосов
/ 05 марта 2012

Ну, как только вы конвертируете в git, было бы довольно хакерски настроить некоторые ветки для SVN.Я бы сказал, что эти «пользователи» должны учиться или уходить.Если вам нужны функции git для более эффективного управления филиалами, тогда это правильное решение независимо от S & U.

С точки зрения управления несколькими производственными выпусками, я предложу вам модель, для которой я придумал Net-SNMP , который работает очень хорошо.У нас есть несколько веток рабочей версии, которые поддерживаются в течение ряда лет, и поэтому отслеживание исправлений всегда было проблемой в SVN.В нашем новом Workflow мы намного счастливее и, как правило, испытываем достаточно хорошие чувства, что мы не сбрасывали патчи в ту или иную ветку из-за реального слияния (в отличие от SVN, где мы должны были сделать вручнуюуверен, что каждая ветвь содержала каждый патч.)

...