Стратегия работы с ветками и тегами в git

Общие положения

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

Вносить изменения в репозитории, чьим хозяином не являешься, не разрешается (в ветку master вносить изменения может только руководитель команды).

Все модули делятся на две части:

  • уровень сервисов (например модули сервиосов контрактов, процедур и т.д.)
  • уровень framework

Команда разрабатывающая сервис, при подключение модулей в composer.json

  • Для модулей уровня framework - ВСЕГДА УКАЗЫВАЕТ ТЕГ
  • Для модулей входящих в чужой сервис (т.е. команда не является хозяином данного модуля) - ВСЕГДА УКАЗЫВАТСЯ ТЕГ
  • Для модулей образующих разрабатываемый сервис (т.е. команда является хозяином данного модуля) - УКАЗЫВАЕТСЯ СКВОЗНАЯ ВЕТКА

Внесение изменений в модуль

  • Возникает потребность внести изменения в модули Framework
    • Если изменения нужны одной команде
      • Проверяется есть ли возможность реализовать функционал на уровне сервиса
      • Если возможность есть, то функционал реализуется в рамках разрабатываемого сервиса
      • Если возможности нет, то в модуле реализуется точка расширения, позволяющая вынести функционал на уровне сервиса
    • Если изменения нужны нескольким командам
      • В отдельной ветке реализуется требуемая функциональность
      • Пишутся тесты под внесенные изменения, если тестов нет, то пишутся заново
      • Отправить Merge Request руководителю команды, являющейся хозяином модуля
      • Хозяин модуля принимает request, переносит изменения в master, создает новый тег
  • Возникает потребность внести изменения в модули сервиса
    • Команда которой нужны изменения, является хозяином модуля
      • Создается ветка под Feature. При релизе данные попадают в master, создается новый тег.
    • Команда которой нужны изменения, не является хозяином модуля
      • В отдельной ветке реализуется требуемая функциональность
      • Отправить Merge Request руководителю команды, являющейся хозяином модуля
      • Хозяин модуля принимает request, переносит изменения в master, создает новый тег

Схема внесения изменений в модули