At most places you will find the consensus over committing the Gemfile.lock while committing changes to the your repository. But, I beg to differ.
Gemfile is the main file responsible for holding the names and the versions of all the dependencies of your current project. So once you pull and do ```bundle install``` , the bundler picks up the versions and the source to download them, from the Gemfile. Once the install is over Gemfile.lock is automatically created with the list of the gems (with versions) required by your project along with their further dependencies on other gems(with versions).
I agree that when a ```git pull``` is done from a repository which contains Gemfile.lock, the bundler will read this Gemfile.lock to load all the dependencies required for this project with the versions, instead of using Gemfile. However, in a situation where you uninstall a gem(may be because it was causing errors) and update Gemfile but forget to do ```bundle install``` (as you already have the requisite gems) to update Gemfile.lock, the wrong file(Gemfile.lock) gets committed. And in future whoever does a pull and does ```bundle install``` will get the gems from Gemfile.lock which are not required and may encounter the same errors that you had faced with the wrong gems .ie. the inconsistency and error propagates further. Imagine this situation when the amount of people doing pull from your repository is huge.
So in my opinion these conflicts could be sorted by only committing the correct Gemfile and let others create their own Gemfile.lock files. Also this way you can uphold the DRY principle(Don’t repeat yourself) by not mentioning in two files the gems and the versions to be used.