#git #version-control #branch #fork
#git #управление версиями #ветвление #разветвление
Вопрос:
Я ищу несколько идей относительно того, как разветвить мое приложение, чтобы иметь его версию с ограниченными возможностями.
Позвольте мне привести гипотетический. Допустим, мое настольное приложение взаимодействует со всеми веб-браузерами. Я вступаю в партнерство с ребятами из Google Chrome, которые хотят выпустить версию моего приложения, которая работает ТОЛЬКО с их браузером, и исключит IE, Firefox и т.д.
Как бы я это сделал? Я мог бы создать отдельную ветку в git, а затем дважды запустить свой скрипт сборки, переключая ветки между ними. Я мог бы также просто скопировать полный каталог кода и выполнить сборку из каждого каталога.
Проблема, которую я предвижу, заключается в том, что я хочу, чтобы исправления в моей полной программе автоматически обновлялись и в ограниченной версии. Вероятно, есть и другие проблемы, о которых я пока не догадываюсь. Итак, я ищу руководство.
Спасибо
Ответ №1:
Если вы что-то исправите в своей полной программе, то вы, очевидно, запустите свой скрипт сборки для проверки ошибок регрессии, верно? Так что, возможно, целевой скрипт сборки мог бы быть вариантом. Я бы сказал это или изучил возможность адаптации использования флагов (ребята из Asana — большие фанаты).
Комментарии:
1. 1 для флагов. Это можно сделать с помощью ветвей, но в этом случае поддерживать флаги намного проще.
2. спасибо, я думаю, что это будет лучший способ, тогда мне не придется беспокоиться о дублировании исправлений. У меня может быть просто одна ветвь кода и отмечать функции, которые я хочу (или отмечать функции для сборки)
Ответ №2:
В зависимости от типа приложения, вы хотите оставить его как можно более мультиплатформенным. Если вы создаете два отдельных источника, у вас действительно есть две отдельные программы — лучше иметь два отдельных репозитория (где один может быть разветвлен от другого).
Ветви имеют свое место для смежных подпроектов, таких как «feature-kitchensink» или для разграничения между версией разработки («develop-1.1») и master («мастер»). Идея в том, что вы хотите, чтобы исходные тексты в каждой ветке были достаточно похожи, чтобы их можно было объединить позже.
Ветви и репозитории в git дешевы, не бойтесь использовать то, что вам нужно.
Ответ №3:
Проблема, которую я предвижу, заключается в том, что я хочу, чтобы исправления в моей полной программе автоматически обновлялись и в ограниченной версии. Вероятно, есть и другие проблемы, о которых я пока не догадываюсь. Итак, я ищу руководство.
Вы можете выбирать коммиты между ветвями, предполагая, что они не конфликтуют с текущим рабочим деревом. Если вы сделаете фиксации исправления как можно более точными для одной ветви, вы должны быть в состоянии перенести их на другую просто отлично — возможно, вам потребуется настроить исправление в соответствии с текущим кодом, но это произойдет независимо.
Ответ №4:
Обычно, если функциональная ветвь отличается от родительской ветви главным образом удалением некоторых разделов кода, извлечение из родительской ветви обновит весь общий код, как и ожидалось. Если удаленные разделы будут изменены, вы, скорее всего, получите конфликт, но его довольно легко разрешить.
С другой стороны, в этом сценарии я бы сказал, что добавление конфигурации, которая отключает некоторые функции во время сборки, было бы более простым решением. (То, как вы это сделаете, будет зависеть от используемого вами языка и инструмента сборки.) Вы все еще могли бы разместить эту ограниченную версию в отдельной ветке и добавить
if(someConfigVariable){
includeSomeCode()
}
вместо удаления ненужного кода в коде, скорее всего, это упростит слияния.