Структура репозиториев плагинов, которые включены в другие репозитории как подмодули - PullRequest
0 голосов
/ 09 октября 2019

У меня есть следующий вызов. Существует универсальный класс ClassA. У него есть дочерние классы ClassB ClassC и другие - и у каждого из них может быть несколько дочерних объектов, это плагины. Это будут плагины многократного использования, поэтому я хотел бы хранить их в репозиториях, чтобы делиться ими по проектам. Также эти плагины будут изменены при использовании в проектах - будут исправлены некоторые ошибки / проблемы, будут добавлены новые методы. Таким образом, я хотел бы иметь возможность отодвигать изменения от проектов к репозиториям плагинов, чтобы там всегда был актуальный код. Я хотел бы использовать эти плагины в моем проекте. Таким образом, я рассматриваю 3 варианта.

  1. ClassA - это отдельный репо. ClassB, ClassC и т. Д. Также являются отдельными репозиториями и используют репозиторий ClassA в качестве подмодуля. Тогда структура папок будет выглядеть так:

ClassB Repo |---- ClassA/ |---+ ClassB/ |---+ plugins/ |---- Plugin_B_1/ |---- ... |---- Plugin_B_N/

Аналог, ClassC:

ClassC Repo |---- ClassA/ |---+ ClassC/ |---+ plugins/ |---- Plugin_C_1/ |---- ... |---- Plugin_C_N/

Тогда яможет включать репозитории ClassB и ClassC в мою основную папку репозитория как подмодули -> но будет дублирование кода (ClassA совместно используется в обоих каталогах). Я использую LabVIEW и TestStand, поэтому, когда TestStand будет загружать методы ClassB / ClassC, у него будут проблемы с зависимостями - поскольку в памяти будут одни и те же методы, загружаемые из разных мест. Это «особенность» TestStand, мы должны с этим смириться, но тогда это означает, что 1-й метод не совсем подходит.

Имеют структуру, аналогичную 1-му методу, но основной проект будет включать сборку из проектов ClassB и ClassC. Эта сборка будет выполнена так же, как структура папок в репозиториях, но они будут скопированы в основной проект следующим образом:

|---- ClassA/ |---+ ClassB/ |---+ plugins/ |---- Plugin_B_1/ |---- ... |---- Plugin_B_N/ |---+ ClassC/ |---+ plugins/ |---- Plugin_C_1/ |---- ... |---- Plugin_C_N/

Таким образом, ClassA будетпредставить только один раз. При копировании сборок ClassB / C папка ClassA будет «перезаписываться» друг другом - но это нормально. Что такое NOK, так это то, что: - изменения плагинов должны выполняться только в репозиториях - потому что я не могу скопировать встроенный код обратно в репозиторий;- после каждого изменения, сборка должна быть сделана, дополнительная работа - особенно, когда плагины не "стабильны", и изменения нужны довольно часто.

Все классы / плагины хранятся в одном репозитории. Его структура будет иметь вид:

|---- ClassA/ |---+ ClassB/ |---+ plugins/ |---- Plugin_B_1/ |---- ... |---- Plugin_B_N/ |---+ ClassC/ |---+ plugins/ |---- Plugin_C_1/ |---- ... |---- Plugin_C_N/ ... |---+ ClassN/ |---+ plugins/ |---- Plugin_N_1/ |---- ... |---- Plugin_N_N/

И затем этот репозиторий будет включен в основной репозиторий проекта как подмодуль. Проблема в том, что проекту не нужны все плагины;лучше их как-то отфильтровать. Здесь я вижу 3 способа: 3.1. Из основного репо с плагинами я бы создал fork -> и удалил из него ненужные плагины. Затем раздвоенный репо будет включен в основной проект в качестве субмодуля. Недостатки в том, что при обновлении плагинов я бы хотел внести изменения в репозиторий основных плагинов. Но в этом случае мне нужно переместить его в разветвленное репо, а затем из разветвленного в основное -> и обработать изменения «вручную», b / c удаленных плагинов в разветвленном репозитории (которые присутствуют в основном репозитории). 3.2. Аналогично предыдущему, но разница в том, что в основном репо будет не форк, а отдельная ветка. 3.3. Хранилище плагинов включено в основной проект, но основной проект включает некоторые настройки, которые отфильтровывают ненужные плагины из подмодуля. Какой-то .gitignore для подмодуля вне подмодуля, на уровне основного репо. Но я полагаю, что такой опции не существует - если основное репо содержит файл .gitignore для субмодуля, то субмодульное репо в любом случае будет отслеживать измененные файлы в субмодуле. Таким образом, трудно обрабатывать нажатия на репо основных плагинов из подмодуля.

Есть ли способ, как решить эту проблему? Я считаю, что это какая-то распространенная ситуация, но я не могу найти решение в настоящее время ... Большое спасибо заранее!

...