FanatPHP, я тоже так делал, достаточно давно и когда не были Doctrine, AR и иже с ними. Сейчас я хочу признать что это бесполезная трата времени. Решать стоит практические задачи, а не изобретать велосипеды
Zimaell, партнерка это для магазинов, AWS это платформа для создания своих проектов. Скорее всего туда стучитесь, только туда могут не пустить просто потому что. Например, если вы из России или стран СНГ. Или по тому что сегодня понедельник.
Виталий Столяров, ага. Вот мы и попались, как говорится. Налицо отсутствие постановки работы по гайдлайнам)
Обычно такая проблема происходит в модульных проектах, когда есть зависимости и нет тестов.
Как это делают в больших компаниях:
- делается множество репозиториев
- каждый репозиторий обязан включать тесты и версионирования через теги
- единый проект собирается исключительно через пакетный обработчик (composer, npm, maven, pip ...) Для языка разработки
- все эти репозитории независимо разрабатываются и общаются исключительно на уровне интерфейсов чтобы не было необходимости лезть в проекте внутрь зависимости и ее дебажить - она работает как черный ящик
Виталий Столяров, тут просто большинство разговоров о подобных проектах. Но в таком чистом виде таких систем контроля версий просто н существует просто по причине что самый крупный юнит в системе контроля версий это репозиторий и выше него нулевая видимость. Так что либо несколько репозиториев либо один. Пока деже непонятно что вас не устраивает в нескольких репозиториях и для чего это все
тогда смысл комментировать вопрос, не понимая сути дела?
чтобы как раз и прояснить делали и на основе их предложить решение
Где это сказано?
По тому что в системах контроля версий вообще уже десятки лет не существует подобного функционала - то есть git submodules самое близкое из того что требуется, но тебе это не нравится.
Я пока жду услышать что у тебя какой-то модульный проект или проекты и тебе нужно воспользоваться разными репозиториями для какого-то менеджера пакета (в зависимости от того что ты делаешь)
Gruzchick, тогда вы не с той стороны подошли. В этой жизни, наверное, только философы решают абстрактные задачи. Делайте все в комплексе, но по частям. Опишите сущности и из составляющие, определитесь как будет выглядеть фронт ( я не про дизайн, а технологии и действия, список экранов) и как он будет получать данные и только после этого начинайте проектировать API. Чтобы решать сферическую задачу в вакууме нужно иметь очень много опыта)
Кодить ты умеешь когда ты можешь написать код, соответствующий тз с интерфейсом входа и выхода. А это уже инжиниринг)