Форкинг новой версии моего приложения

Question

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

Позвольте мне дать гипотетическую версию.Допустим, мое настольное приложение взаимодействует со всеми веб-браузерами.Я вступаю в партнерские отношения с ребятами из Google Chrome, которые хотят выпустить версию моего приложения, которая работает ТОЛЬКО с их браузером, исключая IE, Firefox и т. Д.

Как мне поступить?Я мог бы создать отдельную ветку в git, а затем дважды запустить мой скрипт сборки, переключая ветки между ними.Я также мог бы просто скопировать каталог с полным кодом и собрать из каждого каталога.

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

Спасибо

Answer 1

Если вы исправите что-то в своей полной программе, то, очевидно, вы запустите скрипт сборки, чтобы проверить ошибки регрессии, верно? Так что, возможно, целевой сценарий сборки может быть вариантом. Я бы сказал это или посмотрел на адаптацию использования флагов (парни из Асаны - большие фанаты ).

Answer 2

Обычно, если ветвь функции отличается от родительской ветки в основном удалением некоторых разделов кода, извлечение из родительской ветки обновит весь общий код, как и ожидалось.Если удаленные разделы будут изменены, вы, скорее всего, получите конфликт, но его довольно легко разрешить.

С другой стороны, в этом сценарии я бы сказал, что добавление конфигурации, которая отключает некоторые функции во время сборки, будетболее простое решение.(То, как вы это сделаете, будет зависеть от языка и инструмента сборки, который вы используете.) Вы можете по-прежнему иметь эту ограниченную версию в отдельной ветке и добавлять в код

if(someConfigVariable){
    includeSomeCode() 
}

вместо удаления кода, который выне нужно, скорее всего, облегчит слияния.

Answer 3

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

Вы можете выбирать коммиты между выбранными ветками, предполагая, что они не конфликтуют с текущим рабочим деревом. Если вы сделаете фиксации исправления настолько точными, насколько это возможно для одной ветви, у вас будет возможность выбрать их для другой точно - вам может потребоваться настроить исправление, хотя в соответствии с текущим кодом, но это произойдет независимо от *. 1005 *

Answer 4

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

В ветвях есть место для касательных подпроектов, таких как "feature-kitchensink" или для расхождения между версией разработки ("velop-1.1 ") и master (" master "). Идея состоит в том, что вы хотите, чтобы источники в каждой ветви были достаточно похожими, чтобы их можно было объединить позже.

В git дешевые ветки и репозитории, не бойтесь использовать то, что вам нужно.