Вот моя проблема - у меня есть кодовая база, которую нужно развернуть в трех разных средах.90% кода является общим.Остальные 10% уникальны для каждой среды.Я хотел бы использовать рабочий процесс git-flow (master ,velop), но мне кажется, что мне нужен второй слой ветвей "Develop" (Develop_a, Develop_B, Develop_C), которые ветвятся от "Develop".Если бы я сделал это, я мог бы сделать общие изменения кода в «разработке», а затем периодически объединять изменения разработки в Develop_a, Develop_b и Develop_c.В то же время я могу работать над вопросами, относящимися к Develop_a, Develop_b и Develop_c в филиалах этих филиалов.
Использование этого подхода делает «основную» ветвь практически бессмысленной с точки зрения того, что она является местом для выпускаемого программного обеспечения.develop_a ,velop_b и develop_c - это ветви, которые содержат полный набор программного обеспечения, которое должно быть выпущено для каждой среды.Я пытаюсь выяснить, есть ли какой-то рабочий процесс или лучшая практика, которая поддерживает это.Я не думаю, что разные репозитории для a, b, c имеют смысл из-за большого количества общего кода.
Я думаю, что лучшим / долгосрочным решением было бы реорганизовать код таким образом, чтобы создавать интерфейсы и классы, поддерживающие уникальностьvelop_a, develop_b и develop_c, с версией (a, b, c).) Развертывание решается во время выполнения (существуют другие проблемы и осложняющие факторы, которые могут сделать это невозможным).Я полагаю, что у меня есть возможность исследовать этот подход в долгосрочной перспективе, но у меня также есть краткосрочная потребность в создании рабочего процесса, чтобы люди могли начать работать над этими версиями, чтобы мы могли вывести их в поле для тестирования вближайшее будущее.
Любые мысли будут наиболее ценными.