Все это кажется классным, но есть один недостаток: проекты, созданные из наших скелетов, не разветвляются от них, они клонируют репозиторий скелетов, а затем переносят свой новый проект в другое репо.
Но это разветвляется.
Git - распределенная система. Коммиты сохраняют свою идентичность при перемещении между хранилищами. Если они клонировали ваш репозиторий и поместили его в свой, ветки имеют общую историю, поэтому они могут извлекать из вашего репозитория и в любой момент объединить базовый уровень со своим проектом.
Операция «разветвления» GitHub, GitLab, BitBucket и им подобных - это просто клон на стороне сервера. Если они сделали клонирование вручную, менеджер хранилища не будет знать, что он может выполнить слияние, поэтому им, возможно, придется делать это и вручную, но ничто не мешает ему.
Тем не менее, слияние плохо сочетается с главными вещами. Для базовой линии и проектов, построенных на ее основе, обычно лучше иметь базовую линию и настройки как некие слои, объединенные системой сборки, с базовой линией, извлеченной как sumbodule или загруженной системой сборки как зависимость.
Обновление:
Но я узнал, что на самом деле новые проекты не создаются таким образом, и поэтому они не являются форками.
Есть еще способ обойти это. Он часто используется специалистами по сопровождению пакетов (например, в Debian) для отслеживания изменений из вышедших выпусков, которые имеют версии в разных или непубличных системах контроля версий. Он работает, поддерживая ветвь «вверх по течению»:
Первоначальный импорт в репозиторий проекта (в нисходящем направлении) является прямой копией некоторой ревизии скелета (в восходящем направлении), а затем в нее вносятся изменения. Когда пришло время слиться с более новым скелетом (восходящим), создается новая ветвь (upstream), в нее копируется и фиксируется более новая версия скелета. Эта ветвь затем объединяется в master, чтобы ввести более новый скелет.
Поскольку алгоритм трехстороннего слияния заботится только о текущих состояниях и самом последнем общем предке, а не о ревизиях между ними, не имеет значения, что у вас нет этой истории. Только не теряйте ссылку upstream впоследствии, чтобы вы могли обновить ее в следующий раз, когда захотите объединить новый скелет.
Этот рабочий процесс использовался еще до Git и был там еще важнее, потому что централизованные системы не могут реплицировать историю между репозиториями, как распределенные. Он даже описан в руководстве CVS как «ветви поставщиков». Это также явно один из сценариев использования дизайна для Git, и важная причина, почему Git угадывает переименования во время слияния, а не отслеживания идентичности файла - потому что при импорте tarred / zip-релиза в ветку поставщика у вас нет информации о переименовании .
Обратите внимание, что вы значительно помогли бы этому рабочему процессу, выполнив явно пронумерованные выпуски скелета. Это упрощает отслеживание того, какая версия была импортирована и объединена в каждом последующем проекте.