Как я могу иметь каталоги в моем Git-репозитории, которые я обычно не проверяю?

Question

Я рассматриваю вопрос о переносе своих репозиториев веб-сайтов Subversion в Git, но я не уверен, как структурировать свои новые репозитории. В SVN я структурировал свои репозитории так:

• ветви
• теги
• багажник
  
  • supportdocs
  • webdocs

У меня под стволом есть каталог для любых вспомогательных документов (документы Word, файлы Photoshop и т. Д.) И каталог webdocs, в котором находится настоящий веб-сайт.

Затем я бы извлек только каталог webdocs для использования в Eclipse. Однако, с помощью git, если я сделаю существующий транк корнем моего репо, клон захватит все это и затруднит работу только с моими файлами webdocs.

Должен ли я создать два репозитория, один для поддержки документов и один для веб-файлов? Или есть способ, которым я могу сохранить их обоих в основной ветке, но работать только с подпапкой?

Answer 1

У вас могут быть отдельные (не связанные) ветки с сопроводительными документами, если они на самом деле не относятся к какой-либо конкретной версии ваших основных документов.

(По сути это похоже на наличие двух отдельных репозиториев, но у вас есть все вместе. С git-new-workdir вы можете создать новый рабочий каталог для того же репозитория.)

В качестве примера я использую нечто подобное в моем jsch-documentation хранилище на Github . У меня есть дерево несвязанных деревьев коммитов (и веток):

• JSch-связанные: master, better-examples, directtcp-ip-bug, tarballs, hostbased-auth, swingworker-example
• Связанные с JZlib: jzlib-tarballs, jzlib-source
• Веб-страницы (в основном, сгенерированные Javadocs): gh-pages

Фактически, это могли быть три разных репозитория (кроме того факта, что github генерирует веб-сайты из ветви gh-pages).

Answer 2

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

Answer 3

Могу ли я предположить, что стоило бы прочитать немного больше о «git» и парадигме DVCS, потому что она настолько отличается от процессов управления версиями 19-го века, которые охватывают все процессы централизованного управления.

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

Answer 4

Вам понадобятся два отдельных репо.

git не имеет возможности извлекать отдельные подпапки репо и работает только с этими

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