Добавить пакеты php composer в мой git-репозиторий
Я установил composer и добавил несколько пакетов через 'composer install'. Он установил их по пути "my_project\vendor", но некоторые пакеты были клонированы с помощью git, поэтому, когда я зафиксировал "my_project", эти клонированные пакеты были проигнорированы.
Проблема заключается в том, что когда другие разработчики клонируют "my_project", им не хватает пакетов, которые были проигнорированы. Есть ли способ автоматически добавлять пакеты в "my_project", чтобы другие разработчики брали их у меня?
Я думаю, что это должно быть сделано с использованием подмодулей, но я не знаю, как автоматически добавлять каждый новый пакет из composer как подмодуль в мой проект.
2 ответа
Предисловие: Джорди - я люблю композитора, продолжаю в том же духе, и если я ошибаюсь, дайте мне знать, и я обновлю свой рабочий процесс и отредактирую сообщение:D
К сожалению, это не "общая рекомендация" в зависимости от того, кого вы спрашиваете, это, безусловно, только для разработчиков. И предостережения относительно использования практики, предписанной в FAQ композитора, имеют гораздо больше соображений, чем я могу здесь изложить. Поэтому я оставлю пару основных моментов для рассмотрения другими.
По словам самого Селдака, композитор на самом деле не на 100% стабилен, намного лучше, чем год назад, но все равно очень активный проект. Поэтому полагаться на то, что composer реализует идентичную среду на сервере dev против промежуточного сервера против рабочего сервера, не будет общей рекомендацией какой-либо группы QA / Deployment. Это не означает что-то незначительное для Джорди, а скорее является выражением дурацкой природы народов QA.
В разделе "Часто задаваемые вопросы" говорится, что при объединении библиотек поставщиков в ваш собственный репозиторий необходимо:
Ограничьте себя установкой отмеченных выпусков (без версий разработчика)
Однако если вы используете composer для управления своим CI или автоматическим развертыванием, то применимо то же ограничение - только в большей степени - потому что развертывание тега master или dev в вашей производственной среде может сильно отличаться от пакета, который вы тестировали при подготовке всего за день или даже час назад.
Даже вне изменений, внесенных в сторонние библиотеки (которые могут быть решены с использованием только версий с тегами, независимо от dev или производственных развертываний), если вы не можете полагаться на то, что composer делает одно и то же каждый раз, вы рискуете ввести ошибки в производство. На самом деле это не тот случай риска, о котором я бы беспокоился, но опять-таки я тоже разработчик;) Но проблемы могут возникнуть в результате простых изменений, подобных этому, если вы не поддерживаете одинаковую версию composer.phar во всех средах, Вы могли бы действительно испортить промежуточный или производственный сервер.
Другая важная проблема, которая у меня есть, действительно связана со всеми пунктами, перечисленными под этим заголовком:
Хотя это может быть заманчиво для фиксации в некоторой среде, это приводит к нескольким проблемам:
Я не рассматриваю последствия как проблемы, но вместо этого выгоды! Большое хранилище vcs не так уж важно в современных средах с высокой пропускной способностью. И если вы не используете очень активную библиотеку вендоров, ваши различия не будут такими большими. Даже если бы они были большими, все системы git / hg / dvcs способны повторно использовать чанки, сжимать чанки и держать всех ваших уток подряд. Более того, они предупреждают разработчика о внесении изменений в эти пакеты, и diff -w отличный общий обзор всех наборов изменений, особенно если вы используете теги dev / master.
Дублирование истории всех ваших зависимостей в вашей собственной VCS.
Это сформулировано немного неверно, оно не будет дублировать всю историю коммитов в вендорной библиотеке, только один коммит (ваш коммит), покрывающий полную дельту между настоящим моментом и последним запуском обновления композитора, что привело к изменениям. Вы, вероятно, не обновляете все свои библиотеки каждый раз, когда обновляете, даже если вы не указываете отдельные пакеты. И если вы случайно обновили библиотеку вендора, вы можете легко вернуться, тогда как, если вы сделали это для тега dev / master и это нарушило вашу среду, вам нужно было бы выяснить, какую версию вы ранее использовали, и указать тег в composer.json и обновите снова, чтобы вернуть его. git checkout /vendor/3rdpartylib --force просто кажется мне проще
Добавление зависимостей, установленных через git, в git-репозиторий покажет их как подмодули. Это проблематично, потому что они не являются реальными подмодулями, и вы столкнетесь с проблемами.
В идеале, композитор даст вам возможность конфигурации. Он может автоматически удалять каталог.git из git pulls и автоматически изменять каталог (или временно его) перед обновлением библиотеки, когда и только когда существует обновленная версия. И сделать это будет гораздо надежнее, чем оставить этот ручной процесс на усмотрение отдельных разработчиков. Существует равное количество причин для интеграции библиотек поставщиков в репозиторий с контролем версий, поэтому выбор действительно зависит от деталей вашей ситуации.
Самая большая причина для создания версий всех ваших файлов - это возможность надежного развертывания именно того пакета, который вы тестировали в процессе разработки, для подготовки к производству, что является основным назначением vcs и автоматических развертываний для начала. Если вы не сконфигурируете свою среду разработки для использования определенных тегов для каждого пакета и не будете управлять версиями вашего composer.phar, вы не должны полагаться на composer для развертывания вашего программного обеспечения.
В идеале вы должны просто добавить vendor/ в ваш.gitignore, и тогда каждый разработчик проекта запустит установку composer, чтобы установить его вендоры.
Вы можете прочитать раздел часто задаваемых вопросов о привлечении поставщиков для более подробной информации.