Just do IT

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

CONFLICT (content): Merge conflict in composer.lock
Automatic merge failed; fix conflicts and then commit the result.

Решение любого конфликта едва ли доставляет удовольствие, но этот требует особенного порядка действий. К счастью это совсем несложно и нам не составит труда это сделать. Сейчас мы рассмотрим решение конфликта в composer.lock.

Чего делать точно не стоит

Ни в коем случае не стоит руками объединять изменения в composer.lock, как вы наверняка делаете это в других файлах. Это сгенерированный файл, так что при ручных изменениях он сломается с вероятностью 99%. Этот совет, кстати, применим не только для ситуаций с конфликтом, а является предостережением для любых походов в composer.lock вообще.

Еще одной плохой идеей будет такое:

git merge --ours composer.lock

Так мы просто проигнорируем изменения, которые сделал другой разработчик и наживем себе врага 🙂

Решение

Столкнувшись с конфликтом такого рода необходимо принять версию composer файлов из удаленной ветки

git checkout origin/{base} -- composer.lock composer.json

Фигурально выражаясь тут действует “правило тапок”: кто первый слил свои изменения в репозиторий, тот и прав. После того как мы приняли чужие composer файлы, мы можем применить свои изменения:

composer require {new/package} --update-with-dependencies
composer update {existing/package}

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

На этом я прощаюсь с моими читателями и желаю им как меньше меньше конфликтов в коде и вне его 🙂

Творческий перевод этой статьи.