Толкая поддеревья в git-репо

Question

Я довольно новичок в Git: я из SVN, и там я нашел действительно мощную функцию: external. Здесь, в Git, я не нашел ничего похожего:

• подмодули идеально подходят для добавления модулей проекта, которые не всегда требуются. Они должны быть инициализированы после клонирования репо, и вы не можете включать только подкаталог исходного проекта.
• поддеревья действительно хороши для добавления библиотек (они также допускают включение подкаталогов), но их нажатие - настоящая боль.

Итак, сценарий таков: у меня есть проект, в который я хочу включить несколько библиотек. Я хочу возможность изменить все эти библиотеки и помещать их в свои собственные репозитории. Более того, некоторые из этих библиотек являются подкаталогами более крупных проектов (например, если проект включает также демонстрационные файлы или файлы readme, я не буду включать эти каталоги в свой проект).

Как я могу это сделать?

Я пробовал:

• http://progit.org/book/ch6-7.html + http://posterous.timocracy.com/git-sub-tree-merging-back-to-the-subtree-for (объединение только подкаталога не разрешено, или я просто не вижу его);
• http://www.tipstank.com/2011/02/21/git-subtree-notes-and-workflows/ (как и выше, не обрабатывать включение subdir);
• http://psionides.eu/2010/02/04/sharing-code-between-projects-with-git-subtree/ (ничего не вижу в толкании);
• http://h2ik.co/2011/03/having-fun-with-git-subtree/ (ничего не вижу в толкании)

Что ж, если вы достигли этой точки, спасибо за ваше терпение, теперь я хотел бы попробовать что-то еще, потому что сейчас мой вывод таков: "выдвижение поддерева не разрешено в Git" ç_ç

Answer 1

Пара замечаний из комментариев:

• Подмодули git отличаются от svn external
• любая модификация, сделанная в подмодуле может быть отправленак своему собственному удаленному репо .
• " Планирование макета репозитория для переноса git " показывает, что вы не всегда можете использовать субмодули напрямую, поскольку структура каталогов не будет именно тем, что вам нужно.

Поэтому я рекомендую:

• загрузить (git checkout) родительское репо и все его подмодули
• , создав в другом месте правильную структуру с символической ссылкой наподмодули (или подкаталоги подмодулей для достижения того, что вам нужно.
• периодически возвращайтесь к репозиторию git ain для обнаружения любых изменений (донов из другой структуры каталогов, созданных вне Git) в порядкезафиксировать и отправить все модификации подмодулей, а затем зафиксировать и отправить родительское хранилище.

git checkout

parent repo
  +
  +--> main project
    +
    +-> mainDir1
    +-> mainDir2
  +--> lib1
    +
    +-> lib1Dir1
    +-> lib1Dir2
  +--> lib2
    +
    +-> lib2Dir1
    +-> lib2Dir2

И ваш собственный проектСтруктура директории ect (например)

  +--> main project (symlink to ../parent/main project)
    +
    +-> mainDir1
    +-> mainDir2
    +-> lib1Dir1    (symlink to ../parent/lib1/lib1Dir1)
    +-> lib1Dir2    (symlink to ../parent/lib1/lib1Dir2)
    +-> lib2Dir2    (symlink to ../parent/lib1/lib2Dir2)

(обратите внимание, что lib2Dir1 (например) нет, потому что в вашем реальном проекте вам это не нужно)

Answer 2

Решение VonC является изящным, но у него есть недостаток: нет хорошего способа зафиксировать конфигурацию вашего проекта + библиотеки в определенный момент времени.

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

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

В противном случае всегда двигайтесь вперед и никогда не проверяйте более старую версию.