Отправка поддеревьев в репозиторий 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 / (то же, что и выше, не обрабатывать включение вложенного каталога);
• http://psionides.eu / 2010/02/04 / share-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

общий

И ваша собственная структура каталогов проекта (например)

общий

(обратите внимание, что нет никакого генерирующего кода кода (например), потому что в вашем реальном проекте он вам не нужен)

Answer 2

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

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

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

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