Я предлагаю вывернуть таксономию наизнанку.В subversion я предлагаю таксономию, такую как:
companyname/
include/
trunk/
tags/
branches/
libraryA/
trunk/
tags/
branches/
libraryB/
trunk/
tags/
branches/
libraryC
trunk/
tags/
branches/
libraryD/
trunk/
tags/
branches/
application1
trunk/
tags/
branches/
application2
trunk/
tags/
branches/
В git я предлагаю вам создать отдельное репозиторий git для include, libraryA, libraryB, application1 и т. Д. ...
Эта структура позволит вам создавать любые зависимости между различными частями (например, ветвь в application1 может зависеть от нестабильной версии проекта libraryA, в то время как HEAD в application1 может зависеть от стабильной версии проекта libraryA),
Эта структура также хорошо работает с большинством инструментов сборки, таких как maven, rake, buildr, ant и т. Д.
Представленная таксономия выглядит так, как будто она является хорошей структурой для развернутой версии вашего приложения,но не очень хорошая структура для контроля версий.Исходя из опыта, я думаю, вам будет лучше, если вы будете использовать структуру, подобную той, которую я предложил для контроля версий, а затем использовать скрипт сборки (или инструмент сборки) для создания структуры, которую вы перечислили, когда придет время упаковать / развернуть /поставьте ваше приложение.
ОБНОВЛЕНИЕ: Чтобы немного рассказать о том, как может идти рабочий цикл:
Итак, например, допустим, что мы закончили реализацию исправлений ошибок для Application1 (назовем эту версию 1.0.0).Последние и самые большие изменения проверены в application1 / trunk.Эта версия Application1 зависит от библиотеки D v0.5.0.Вы обновляете application1 / trunk / README.txt, отмечая, что эта версия зависит от libraryD v0.5.0.Возможно, что еще важнее, скрипт сборки внутри приложения / trunk знает, как извлечь библиотеку D / tags / 0.5.0.Затем создайте тег (который является просто копией транка в текущем состоянии) в application1 / tags / 1.0.0.
Теперь, скажем, проходит неделя, и другой разработчик обновляет libraryD до версии 1.3.0.Вам нужно улучшить приложение1.Итак, внесите изменения в application1 / trunk.Затем обновите application1 / trunk / README.txt, чтобы сказать, что вы теперь зависите от libraryD v1.3.0 (и, аналогично, новый скрипт сборки для application1 v1.3.0 извлечет libraryD / tags / 1.3.0).Скопируйте application1 / trunk в application1 / tags / 1.1.0.
Теперь вы всегда можете вернуться к application1 / tags / 1.0.0 при необходимости (и быть уверенным, что он будет извлекать код из libraryD / tags / 0.5.0. application / tags / 1.1.0 будет использовать libraryD версии 1.3.0.
И в subversion, и в git тег - это ссылка на набор файлов в данный момент времени. Это означает, чтотеги не занимают много места, поэтому я говорю теги рано и часто; -)