Как использовать подмодули публично, но символические ссылки на один клон локально?

У меня есть первый опыт Git Submodule.

У меня есть несколько проектов, которые зависят от одного и того же подпроекта. Я держу эти проекты в синхронизации, поэтому я использую функцию " git submodule add -b master [URL] branch" (например, git submodule add -b master [URL]).

Хотя я бы хотел, чтобы публичные репозитории GitHub передавали отношения подмодуля, в моем собственном рабочем потоке я бы просто хотел, чтобы на моем диске был один клон общей кодовой базы. Я думал, что могу просто настроить подмодули, а затем сделать переключатель с символической ссылкой. Но когда я это делаю, я получаю следующее:

On branch master
Changes not staged for commit:
 (use "git add <file>..." to update what will be committed)
 (use "git checkout -- <file>..." to discard changes in working directory)

    typechange: draem

Таким образом, Git, по-видимому, видит факт, что это символическая ссылка, а не переход в каталог.

Есть ли какой-нибудь рабочий процесс, где я могу работать с субмодулями, но на самом деле у меня есть только один клон в локальной файловой системе?

ОТВЕТЫ

Ответ 1

Таким образом, Git, по-видимому, видит факт, что это символическая ссылка, а не переход в каталог.

Да, Git увидит такое изменение, потому что этот подмодуль объявляется в родительском репо как специальная запись в индексе.

Создание символической ссылки заменит эту специальную запись файлом другого типа.

Вы можете попробовать сыграть с GIT_WORK_TREE (как в GIT_WORK_TREE " Включение подмодулей в git checkout в GIT_WORK_TREE в hook ").

Но более простым решением было бы:

  • держите свой подмодуль прямо там, где они есть.
  • добавьте еще один клон этого репозитория подмодуля, где вы хотите его (/path/to/sub).
  • обнаружить любые изменения из папки исходного подмодуля с помощью git --work-tree=/path/to/sub status из вашей дублированной папки подмодуля в родительских репозиториях.

Ответ 2

Вы можете связать монтирование подмодуля другого каталога

sudo mount --bind /path/to/main/repo relative/path/to/submodule

Я не могу найти много информации об этом методе, но видел, что он указан в этом подобном вопросе.

Ответ 3

(Оцените другой совет, но ответьте на то, что я решил сделать, потому что это проще всего.)

Поместите клоны подмодулей, которые вы планируете использовать в своих собственных каталогах.

Затем определите, как вам нравится в проектах, каждый из которых имеет свой собственный клон подмодуля (ов), который вы планируете разделить. Как только проекты будут настроены таким образом, что новые пользователи будут получать подмодули нормально, замените каталоги подмодулей на общие символические ссылки на ваш единственный локальный экземпляр, где вы делаете свои изменения, и добавьте их в.gitignore.

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

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

Для проектов на более продвинутой стадии @VonC, вероятно, имеет правильный ответ... не лгать Git, проверять подмодули в соответствующих состояниях и использовать триггеры для управления обновлениями.

Ответ 4

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

Это также может быть хорошим, потому что вы можете развиваться в подмодуле одного из ваших проектов и не влиять на другие.