Нужно ли отправлять в git файл composer.lock?

Поскольку Composer является менеджером зависимостей в PHP и его фреймворках, мы знаем, что каждая зависимость управляется в файле composer.json проекта, но знаете ли вы, что есть еще один важный файл, который более точно обрабатывает зависимости.

Это файл composer.lock.

Что такое composer.lock?

Файл composer.lock поддерживает более глубокую зависимость, т.е. указывает на фактическую фиксацию версии пакета, который мы включаем в наше программное обеспечение.

Возьмем пример и разберемся.

composer.json

Предположим, что ведущий разработчик говорит композитору установить laravel 5.8 с любой последней второстепенной версией, например 37, то есть композитор установит laravel 5.8.37 локально на машине ведущего разработчика. В то же время файл composer.lock будет сгенерирован примерно так:

Composer.lock

...
{
"name": "laravel/framework",
"version": "v5.8.37",
"source": {
"type": "git",
"url": "https://github.com/laravel/framework.git",
"reference": "ce08aaee3a0b8bb58b459b2decf7f25ba7b10fa4"
},
"dist": {
"type": "zip",
"url": "https://api.github.com/repos/laravel/framework/zipball/ce08aaee3a0b8bb58b459b2decf7f25ba7b10fa4",
"reference": "ce08aaee3a0b8bb58b459b2decf7f25ba7b10fa4",
"shasum": ""
},

...

Вторая часть была бы более интересной, если бы ведущий разработчик фиксировал только composer.json, но не composer.lock . Теперь, когда младший разработчик клонирует репозиторий, он, очевидно, будет содержать только composer.json, а пока есть еще одна стабильная минорная версия, предположим, v5.8.40в основном репозитории laravel, поэтому, как только младший разработчик запустит команду composer install / composer update, композитор прочитает composer.json, установить Laravel v5.8.40и локально сгенерировать composer.lock.

По сути, между laravel может быть много различий в коде, v5.8.37и v5.8.40хотя никаких критических изменений нет, но это явно противоречит концепции системы контроля версий, потому что ведущий разработчик работает над laravel, v5.8.37а младший разработчик работает над laravel v5.8.40.

Поэтому, если ни один из них не фиксирует и не нажимает composer.lock, в будущем могут возникнуть катастрофические конфликты с обеих сторон.

Почему мы также должны фиксировать composer.lock?

Это связано с тем, что локально установленный композитор в первую очередь отдаст предпочтение файлу composer.lock, а не composer.json .

Если файл блокировки недоступен в vcs, композитор будет указывать на файл composer.json для установки последних зависимостей или версий.

Файл блокировки фактически указывает на ссылку фиксации для загрузки кода, поэтому исходный код и целевой код остаются неизменными при работе в группах. Здесь вы можете увидеть, что composer.lock относится к фактическому идентификатору фиксации ce08aaee3a0b8bb58b459b2decf7f25ba7b10fa4 для загрузки laravel v.5.8.*.

Поэтому, когда ведущий разработчик фиксирует этот файл в системе контроля версий, младшие разработчики также автоматически будут использовать ту же базу кода, что и ведущий разработчик.

В этом сила composer.lock предотвращать конфликты между командами.

Совет от профессионала

Если вы находитесь на принимающей стороне, то есть на младшем разработчике в команде, всегда используйте composer installвместо этого, composer updateпотому что установка композитора установит только зависимости в соответствии с исходной стороной, то есть ведущим разработчиком, и никакие изменения не будут внесены в файл composer.lock.