Модель ветвления GitHub для нескольких команд для репозитория - PullRequest
Новая
       117

Модель ветвления GitHub для нескольких команд для репозитория

1 голос
/ 11 марта 2019

У нас есть следующая модель ветвления в GitHub для наших приложений, позволяющая выпустить их в нескольких средах.

Общая стратегия ветвления enter image description here

Очки для рассмотрения - В нашей организации несколько команд работают над одним репозиторием с разными сроками выпуска.Как правило, мы следим за еженедельными выпусками, так как через месяц будет 4 выпуска (R1, R2, R3 и R4), несколько проектов (Project-X и Project-Y) могут быть частью одного выпуска.

  • Сведения о филиале

    • master => Стабильная / рабочая копия, доступ к слиянию ограничен членами команды CI
    • release-month-R1 => ветвь еженедельного выпуска (На этапе развертывания, поскольку это сборка слиянием для нескольких проектов), доступ к слиянию ограничен членами CI Team
    • project-A => Ветвь проекта для каждой группы, Запрос защищенного и извлечения и Проверка сервера CI (Build + UT + Code)Метрики качества) является обязательным для продвижения кода.(Развертывание Dev и QA)
    • ft-Project-A-CSS_fix => ветвь возможностей для Project A, открыта для разработки без ограничений.

Ниже приведеныобычные сценарии, через которые мы прошли,

Вариант использования 1

Существуют только те ветки проекта, которые являются частью выпуска текущей недели. Каждый проект является веткойи одна команда внесла свой вклад в эту ветку с несколькими ветвями функций, скажем, Project-X и Project-Y являются частью release-mar-R1.Команда A, B работает над Project-X, Y соответственно.В определенную согласованную дату слияния команды сливают ветки проекта в release-mar-R1 и разрешают конфликты, если таковые имеются, через соответствующую ветку функций проекта путем перебазирования кода.Мы не видели никаких проблем в этом случае использования.Кроме того, мы создаем теги для сборок DEV и STG.

enter image description here

Запросы

• Как восстановить фут-Project-X-1 изменяется после слияния с Project-X?

Вариант использования 2

Ветви проекта, являющиеся частью различных еженедельных выпусков.

  • Project-A будет частью release-mar-R1

  • Project-B будет частью release-mar-R2

После того, как Project-A перешел в производство, разработчики сделают запрос на извлечение для любой существующей / новой функциональной ветви проекта B и объединят изменения R1.Кроме того, если есть какое-либо экстренное исправление / оперативное исправление для R1 до R2, то оно будет объединено с веткой Project-B с PR.

enter image description here

Запросы

  1. Любая опция для автоматической перебазировки других ветвей проекта относится к выпуску R2, когда R1 / исправление объединено с мастером.

Вариант использования 3

Ветви проекта, которые являются частью различных еженедельных выпусков и некоторой будущей разработки илиPOC.

  • Project-A будет частью release-mar-R1
  • Project-B будет частью release-mar-R2
  • Project-C не идентифицировал неделю выпуска, когда дата релиза должна быть согласована с предстоящей неделей релиза.

Приведенная ниже модель работает нормально, если Project-C перебазирован / объединен для каждогорелиз и исправление.enter image description here

Запросы

  1. Когда разработчики пропускают релиз / ebf объединяют изменения, которые затрагивают тот же набор файлов, мы видимИзменения в Project-C отсутствуют, если изменения следующего выпуска пересмотрены.Любые предложения, чтобы избежать этой проблемы?
...