Можно ли сохранять в git папку vendor после composer update?

При использовании менеджера пакетов composer, все необходимые для проекта пакеты сохраняются в папке vendor, при этом общепринятая практика такая, что эту папку добавлять в git нельзя, вместо этого каждый разработчик после git clone должен делать composer install и периодически composer update.
Мне такой подход не очень нравится по следующим причинам:
  1. Если одни разработчик обновил библиотеки, другие должны как то об этом узнать, чтобы обновится у себя
  2. Список библиотек и версии обновляются не очень часто, а при каждом релизе, приходится выкачивать одни и те же либы
  3. В проекте могут быть заняты люди, которые не умеют (или не могут в данный момент) работать с консолью: верстальщики, технические писатели, ревьюер кода (безопасности), сюда же и вопрос оплаты специалиста, которые умеет всё
  4. Нет возможности просто и быстро передать кому-то код, просто расшарив ссылку на гит


Вопрос в том, можно ли сохранять папку vendor в git, насколько это противоречит принятому стилю и какие могут быть проблемы с этим (сейчас самый жирный минус от такого подхода вижу в распухании репозитория) ? Использует ли кто-нибудь такую практику в своих проектах ?
  • Вопрос задан
  • 2451 просмотр
Пригласить эксперта
Ответы на вопрос 4
index0h
@index0h
PHP, Golang. https://github.com/index0h
Если одни разработчик обновил библиотеки, другие должны как то об этом узнать, чтобы обновится у себя

Если другие разработчики делают git pull и не обращают внимания на изменения - это их проблемы. Хорошим тоном является уведомление от автора правок в composer.json, что остальным стоит его обновить.

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

Вообще говоря композер умеет в кэш и одни и те же версии либ тянутся с кэша.

В проекте могут быть заняты люди, которые не умеют (или не могут в данный момент) работать с консолью: верстальщики, технические писатели, ревьюер кода (безопасности), сюда же и вопрос оплаты специалиста, которые умеет всё

Если нужно именно поднять окружение с проектом - настройте vagrant и пропишите в README как им пользоваться конкретно для вашего проекта.
Что касается людей:
* верстальщики - vagrant
* технические писатели - я конечно не в курсе вашего проекта, но я бы доступ даже к репозиторию не дал, максимум - завел отдельный репозиторий для них.
* ревьюер кода (безопасности) - ревьюер, который не может в composer / консоль?? Шутка не удачная.
* сюда же и вопрос оплаты специалиста - лолшто? Это вообще не связано с окружением вашего проекта, ну вот ни капли.

Нет возможности просто и быстро передать кому-то код, просто расшарив ссылку на гит

Если у вас проект НЕ opensource - то такого делать в принципе нельзя. Доступ к репозиторию должны иметь специалисты, которые работают с кодом этого проекта и ни кто другой, а composer тут вот ни капли ни при чем!

Вопрос в том, можно ли сохранять папку vendor в git

НЕТ! Вы придумали НЕ существующую проблему и пытаетесь героически ее решить, только от этого решения будет еще хуже.

насколько это противоречит принятому стилю

на полностью

какие могут быть проблемы с этим (сейчас самый жирный минус от такого подхода вижу в распухании репозитория) ?

1. Вы становитесь вендором кода, который взяли где-то, как следствие вы следите за его обновлением, у изначального вендора и вы проводите аналогичные правки в своем проекте. Если так не делать - баги, найденные в этой зависимости сами себя не пофиксят и этот код будет быстро устаревать.
2. В код зависимости появляется соблаз провести собственные наработки - это то, что делать нельзя, иначе процесс обновления будет сложнее на порядки.
3. Ваш репозиторий разбухнет.
4. Композер вашу зависимость придется явно прописать иначе автолоад может ее не подтянуть.

Использует ли кто-нибудь такую практику в своих проектах ?

Пару лет назад работал на крупном проекте, который начинался до появления композера. Когда зависимостей тьма и ты не знаешь, какие из них содержат артефакты собственных наработок, какие обновляются синхронно с официальными вендорами, а какие тянутся из вне приходится тратить кучу времени на выяснение. Это просранное время.
Ответ написан
@aol-nnov
> другие должны как то об этом узнать, чтобы обновится у себя
ну, ты же гитом пользуешься, да? прям пользуешься-пользуешься?
git fetch origin
git diff --name-only <yourbranch>..origin/<yourbranch> -- composer.json или как он там
Ответ написан
@assets
Back-end developer
vendor лучше не загружать в гит. Зачем собой тащить не сколько mb.

1. Он же разработчик пусть смотрит на коммит и composer.json
2. Не всегда так. Например я один раз поставил и забыл, остальные разработки через гит.
3. Git и Composer это стандарт в области веб-разработки, желательно его должны знать.
4. Делай на тестовым сервере vps.

Убери папку vendor из gitignore. Это очень плохая практика.
Ответ написан
Можно, но смысла нет.
Вместо этого в гит мы кладём composer.lock и повесили гит-хук, который делает composer install при merge и checkout.
После этого проблему как рукой сняло.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы
28 мар. 2024, в 20:46
150000 руб./за проект
28 мар. 2024, в 20:37
50000 руб./за проект
28 мар. 2024, в 20:34
1500 руб./за проект