Solving conflicts in composer.lock

We have all been there:

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

Don’t panic, breathe, let’s walk through this.

Since I joined Usabilla, I have been working once more in a large team. With more people involved in the process of working with composer, adding, updating and removing libraries, merge conflicts are bound to happen. Ideally I would tell you to leave that process to only one person, but that is not realistic in teams over, well, one person. :D

So it will happen, but how do we keep our sanity?

What I AVOID doing.

While reading other blog posts on this I found a practice that I consider not ideal. In most blogposts the first step towards fixing the conflict is usually:

$ git merge --ours composer.lock

What does this do? this will impose your version of the lock file, which seems fine, but has a catch. The catch here is that by ignoring the remote lock file you are discarding any updates done by the other developer.

“but Rafael, semantic version is great nothing will break cause my json file has ^1.2”, I agree, but as a policy I try to make sure our updates are conscious, just for good measure. Also I feel its good to respect the work of other people in your team and not discard those changes unless really required to.

What I DO do.

Its a simple switch around.

First I get the other developers changes:

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

Then you replay your changes on top of this, like:

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

You should know exactly what changes you made, so this should be no problem. Now you have kept all non-conflicting changes and updates from the other developer and applied your changes on top of it and the state of your dependencies is predictable and stable.

Oh, and you obviously run that great test suite after doing this, right?