Avoid merging versioning files in GIT

Question

I use composer which keeps a lock file (composer.lock) where it stores the current librariy status. Whenever I do a composer update, this file gets rewritten. Later GIT tries to merge it on push/pulls.

(We always get conflicts between different developer machines which should be ignored)

Is there a way to keep the composer.lock file in GIT but have something like a "force overwrite" policy applied to it?

Background: So far I kept composer.lock in the gitignore file but that means I have to rerun composer update on all systems (instead of composer install). And that takes too much time.

Answer 1

The way we manage this in our team is to have a "composer lock branch". One of our team members is responsible for managing the composer lock file, and he performs any updates needed if we change the composer.json, if we update our own dependent libraries, or if we just want to refresh the public libraries. Then he will commit this lock file to that branch and push.

When developers are ready to 'opt-in' to the update they merge in from the composer-lock-branch and simply "choose theirs" during the conflict resolution.

The composer-lock-branch is the canonical reference for our json and lock files. It's the only place any changes to the file are sacred. It's the only change that happens on this branch.

But generally speaking, you should be prepared to discard your composer lock file and regenerate it at any time from the composer.json. This is assuming you've set up your dependencies correctly and are not following too many dev-x branches which are in constant flux. If you target your semantic version dependencies to bug-fixes only i.e. to x.y.* (e.g. 1.3.*) then the update process shouldn't break anything and the lock becomes less important.