Как организовать структуру Git-репозитория для нескольких пересекающихся проектов?
Решили перейти с SVN на Git, но возник вопрос как организовать структуру папок и репозиториев. Раньше был один большой SVN-репозиторий типа «svn_repo», в нем в корне лежал всякий хлам, в том числе бинарный, но который тоже нужно держать в CVS и пакеты верхнего уровня типа «com», «ru». Внутри этих пакетов дальше шли папки с исходниками или сторонних библиотек (типа com/adobe/graphics) или наших проектов (типа com/%company_name%/%project_name% или com/%company_name%/%какие-то_общие_самописные_утилиты%). К слову в папках проектов был не только код, но вообще все, связанное с проектом — хмл-ки, графика, музыка и т.д. Таким образом можно было забрать себе или весь репозиторий со всеми проектами, или конкретный проект (svn_repo/com/company_name/project_name). Тут важно, что для работоспособности кода исходники должны лежать в правильной структуре папок в соответствии с пакетом (com.company_name.project_name.Main), к которому они относятся.
В Git'е как будто так делать нельзя (идеологически), вроде бы для каждого проекта нужен свой репозиторий, но тогда не понятно, как «усадить» рядом 2 проекта и папочку с исходниками общей на двоих утилиты? Можно создать для этого три репозитория (которые хранят в себе уже конкретно папку с проектом), а структуру папок (начинающуюся с com/и т.д.) воротить руками — но это дико как-то, по-моему. Можно наверное как-то с помощью «субмодулей» что-то наворотить, но вроде бы получается опять то же самое.
Как все это выглядит обычно? Нормально ли делать 1 большой репозиторий по аналогии со старым «svn-repo»? Не вылезет ли при этом проблем из-за размеров репозитория в будущем? Правильно ли это с точки зрения идеологии Git'а? А может у нас изначально и с свн'ом неверный подход был (сделали так интуитивно, когда проектов стало больше одного, все устраивало)?
