Вы можете приблизиться, но не совсем туда. В частности, репозиторий не может содержать репозиторий. (Дерево работы может, но репозиторий не может.)
При обычном использовании репозиторий Git хранится в подкаталоге с именем .git. Давайте определим эти термины:
- Дерево работ: место в файловой системе, где вы выполняете свою работу.
- Верхний уровень: путь к этому дереву работ без каких-либо дополнительных подкаталоги.
- Компонент пути: см. ниже.
- Вложенный репозиторий: репозиторий и дерево работ, которые содержатся под деревом работ другого репозитория.
Например если /home/users/fred/projects/proj1 - это верхний уровень, он будет содержать каталог с именем .git. Здесь находится сам репозиторий . Остальное в /home/users/fred/projects/proj1 - это дерево работы для этого репозитория. Если есть /home/users/fred/projects/proj1/subproj/.git, то этот .git является вложенным репозиторием в дереве работ для proj1 репозитория.
Коммиты внутри репозитория содержат файлы. Файлы внутри коммитов имеют имена пути. Эти имена путей никогда не начинаются с sla sh, но могут содержать косые черты (всегда прямые косые черты, даже на Windows), поэтому файл может быть назван, например, path/to/file.ext. Когда Git извлекает этот файл в рабочее дерево, он создает подкаталоги path/ и path/to по запросу, так что path/to/file.ext может существовать так, как требует сама ОС (как файл с именем file.ext в каталоге / папке с именем to, которая находится в каталоге / папке с именем path). Различные части, разделенные косой чертой: компоненты пути .
То, что Git не будет , - это сохранить файл или каталог с компонентом с именем .git. 1 Ни одна фиксация не должна содержать файл, который имеет это в качестве любого компонента пути. 2
Это означает, что клонирование репозитория с последующим извлечением некоторой фиксации , никогда не создает подкаталог в рабочем дереве с именем .git. Чтобы содержать реальный репозиторий, вам понадобится Git извлекать подкаталог (не на верхнем уровне) с именем .git, который затем будет содержать все файлы, go в .git fre sh clone - и, за исключением дыр в безопасности, которые теперь исправлены, Git просто не позволит этого.
Вы можете , однако, создавать новые Git репозитории внутри дерево работ существующего репозитория Git. Что вы не можете сделать, так это добавить и зафиксировать их, потому что для добавления одного из них требуется добавить его каталог .git, а имя компонента, включающее .git, запрещено. Git будет (во всяком случае, в наше время) ловко обнаружить, что существует .git, так что это должен быть какой-то подпроект, и в какой-то степени он автоматически попытается подмодулировать вещи. (См. Ниже.)
1 В случае ошибки типа дыры в безопасности очень старые версии Git не проверяли варианты верхнего регистра, что вызывало проблемы при нечувствительности к регистру файловые системы, такие как системы по умолчанию в Windows и MacOS. То есть вы можете сохранить .Git, .GIT, .gIt или что-то подобное. Все современные версии Git также запрещают это.
2 Поскольку существующие коммиты не могут быть изменены, все современные Gits проверяют это в существующих коммитах и отказываются от извлечения такие файлы тоже.
Что вы можете делать
Здесь вы можете сделать две вещи, кроме использования сторонних надстроек например, Google repo. 3 Один более разумный, чем другой, а также более автоматический c.
Вы могли бы:
- создайте вложенные репозитории вручную, т. Е. Создайте репозиторий с рабочим деревом и в этом рабочем дереве создайте вспомогательный репозиторий
, затем непосредственно перед git add -ing и git commit -в рабочем дереве верхнего уровня, которое содержит вложенные репозитории, переименуйте в каталог .git во вспомогательном репозитории:
(cd sub; mv .git XGIT); git add .; git commit -m 'add nested fake repo'
затем, когда вы извлекаете эту фиксацию, вручную go и переименовывайте XGIT в .git
, и теперь у вас есть стандартный вложенный репозиторий в репозитории .
Это неправильный способ и приведен только для иллюстрации.
Или вы можете:
Это правильный способ сделать это , но это означает, что у вас должно быть более одного репозитория GitHub или GitLab: вам нужен один для каждого проекта, фактически, плюс один больше репозитория «суперпроектов», который существует просто для именования всех подпроектов.
Подмодуль - это просто способ, чтобы один репозиторий Git ссылался на другой репозиторий Git. Суперпроект - содержащий репозиторий - имеет файл с именем .gitmodules, который перечисляет информацию о подпроекте для git clone и содержит серию коммитов. Каждая фиксация в суперпроекте перечисляет:
- имя пути подмодуля Git и
- фиксацию ha sh ID, который суперпроект будет
git checkout в подмодуле.
Таким образом, суперпроект автоматически указывает Git на клонирование и git checkout любое количество дополнительных Git репозиториев. У подмодулей есть ряд недостатков, но они действительно работают прямо из коробки.
Чтобы использовать подмодуль, после создания подпроекта .git в дереве работы суперпроекта используйте git submodule add в суперпроекте. Это правильно настроит файл .gitmodules. Если вы разрешите Git автоматически определять наличие вложенного репозитория, Git создает правую часть в commit , но данные, необходимые для clone субмодуля, отсутствуют.
3 Google repo существует в основном потому, что субмодули были гораздо более дисфункциональными в 2005-2012 годах или около того. Субмодули сегодня работают намного лучше.