GitFlow применяется к нескольким вариантам продукта? - PullRequest
Новая
       92

GitFlow применяется к нескольким вариантам продукта?

0 голосов
/ 28 мая 2020

У нас есть веб-приложение, которое мы развертываем в нескольких различных вариантах, где весь код идентичен, но некоторые файлы конфигурации и другие ресурсы различаются в зависимости от развертывания. Мы хотим управлять этим, имея отдельные git ветки для каждого варианта, но также хотим применить подход ветвления, напоминающий GitFlow. Варианты входят в «семейства», то есть может быть одно семейство вариантов Johnson с подвариантами Johnson, Adam и Johnson, Laura. В настоящее время 3 "семейства" и 1-4 подварианта на семейство.

Я вижу, что это можно сделать двумя разными способами. В обоих случаях независимый от развертывания / чистый код помещается в master, dev et c. как в GitFlow.

Подход 1: 

`master`
    `dev`
        `feature-xyz`
        `dev-johnson`
            `feature-johnson-abc`
            `dev-johnson-adam`
        `dev-smith`
    `master-johnson`
        `master-johnson-adam`
    `master-smith`

Подход 2: 

`master`
    `dev`
        `feature-xyz`
    `johnson-master`
        `johnson-dev`
            `johnson-feature-abc`
        `johnson-adam-master`
            `johnson-adam-dev`
    `smith-master`
        `smith-dev`

Каким будет лучший подход? Я чувствую, что у меня недостаточно опыта работы с CI, CD, GitFlow et c. чтобы иметь возможность предвидеть и оценивать последствия каждого из них.

По большей части разработка будет происходить в ветке dev или feature для одного из семейств вариантов или подвариантов, а затем будет объединена в другие семейства / варианты. В некоторых случаях это просто изменения c специфичных для семейства c элементов.

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

В этом случае новая функция будет объединена до master, а затем до главного каждого варианта. Если мы хотим протестировать разные варианты перед объединением в master, т.е. обновить все варианты синхронно c, нам нужно будет объединить «вбок», то есть с johnson-dev до smith-dev.

С подход 1, возможно, это будет более интуитивно понятным: объединить от dev-johnson до dev, затем до dev-smith. Когда все будет готово к публикации sh нового релиза, объедините (через release ветки) до master, затем до master-johnson и master-smith).

Но с оценкой 1 мы закончим с "вбок" объединяет вместо c специфичных вариантов, то есть с dev-johnson-adam на master-johnson-adam.

...