Зависимости проекта Git от GitHub

Я написал фреймворк PHP и CMS поверх фреймворка. CMS зависит от платформы, но платформа существует как отдельная папка в файлах CMS. Я хотел бы сохранить их как отдельные проекты на GitHub, но я не хочу, чтобы у меня возникали проблемы с обновлением проекта CMS при каждом обновлении фреймворка. В идеале я хотел бы, чтобы CMS каким-то образом извлекал файлы инфраструктуры для включения в предопределенный подкаталог, а не для физической фиксации этих файлов.

Это возможно с Git / GitHub? Если так, что мне нужно знать, чтобы это работало? Имейте в виду, что я на очень, очень базовом уровне опыта работы с Git - я могу создавать репозитории и коммитить, используя плагин Git для Eclipse, подключаться к GitHub, и на этом все. В настоящее время я работаю над проектами в одиночку, поэтому мне не нужно было больше узнавать о Git, но я хотел бы открыть его для других в будущем, и я хочу убедиться, что у меня все правильно.

Кроме того, каким должен быть мой идеальный рабочий процесс для проектов с зависимостями? Любые советы по этому вопросу также будет принята с благодарностью. Если вам нужна дополнительная информация о моей настройке, просто спросите в комментариях.

Во-первых, если вы действительно хотите использовать git для этого, тогда подумайте об использовании его функциональности Submodule :

Поддержка субмодулей в Git позволяет хранилищу содержать в качестве подкаталога извлечение внешнего проекта. Подмодули сохраняют свою индивидуальность; поддержка субмодулей просто хранит местоположение хранилища субмодулей и идентификатор фиксации, поэтому другие разработчики, которые клонируют содержащий проект («суперпроект»), могут легко клонировать все субмодули в одной и той же ревизии. Возможны частичные проверки суперпроекта: вы можете указать Git клонировать ни один, некоторые или все подмодули.

Связанная страница содержит подробное обсуждение, включая примеры того, как точно его использовать.

Тем не менее, я бы порекомендовал не использовать вашу систему контроля версий для управления зависимостями, а скорее начать использовать инструмент сборки, который может обрабатывать эти вещи для вас, такие как Maven или Ant . В разработке даже есть специальный инструмент сборки PHP, называемый Phing , но я сам еще не использовал его. Это упоминается в статье, в которой обсуждается ваш вопрос: Контроль версий! = Управление зависимостями .

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

Подмодули Git - отличный способ управления зависимостями проекта git.

Если вы ищете другой подход:

Композитор может сделать все это для вас. Composer - менеджер зависимостей для php. Это синтаксис JSON. Это довольно легко и дешево в использовании.

Подробнее о композиторе:

Composer - это инструмент для управления зависимостями в PHP. Он позволяет вам объявлять зависимые библиотеки, которые нужны вашему проекту, и устанавливает их в ваш проект для вас.

На странице документации вы можете найти пример того, как будет создан ваш файл composer.json:

// Composer.json    
{

    "name": "acme/blog",
    "repositories": [
        {
            "type": "vcs",
            "url": "https://github.com/composer/hello-world"
        }
    ],
    "require": {
        "acme/hello-world": "dev-master"
    }
}

Как только у вас есть файлы composer.json и composer.lock, созданные для вашего проекта, вы можете легко установить ваши зависимости:

composer.phar install или обновите их: composer.phar update или создайте конкретный проект из packagist : composer.phar create-project acmeproject

Недавно я начал использовать инструмент под названием Pundle для управления зависимостями моего проекта. Он поддерживает версии PHP, PEAR-пакеты, Git-репозитории и SVN-репозитории в качестве зависимостей и позволяет легко указывать их через «Pundlefile».

Вы также должны настроить свои зависимости так, чтобы проверки Git / SVN помещались в каталог, который не находится под управлением версией (например, «поставщик»), чтобы у вас был новый старт при каждой проверке и чтобы поддерживать строй вашего репозитория Project.