How to deal with bundler updates (Gemfile.lock) in collaborative context?

Question

I have been a lone programmer on a particular project, but now someone else has joined as collaborator. With just me in the picture, bundler updates have been smooth, and I never thought twice about Gemfile.lock being tracked by Git.

The new collaborator ran bundle install after cloning the repo, and Gemfile.lock was updated as follows:

Gemfile.lock

@@ -141,7 +141,7 @@ GEM        rack-ssl (~> 1.3.2)        rake (>= 0.8.7)        rdoc (~> 3.4) -      thor (< 2.0, >= 0.14.6) +      thor (>= 0.14.6, < 2.0)      raindrops (0.10.0)      rake (0.9.2.2)      rdoc (3.12) @@ -164,7 +164,7 @@ GEM      sprockets (2.1.3)        hike (~> 1.2)        rack (~> 1.0) -      tilt (!= 1.3.0, ~> 1.1) +      tilt (~> 1.1, != 1.3.0)      thor (0.16.0)      tilt (1.3.3)      treetop (1.4.10) @@ -175,7 +175,7 @@ GEM      tzinfo (0.3.33)      uglifier (1.3.0)        execjs (>= 0.3.0) -      multi_json (>= 1.0.2, ~> 1.0) +      multi_json (~> 1.0, >= 1.0.2)      unicorn (4.3.1)        kgio (~> 2.6)        rack 

This change was pushed into a named branch off master. How am I supposed to deal with this change?

Thinking out loud: Do I merge the Pull Request on GitHub? Do I just pull from upstream without a Pull Request at first? Do I run a particular bundler command to sync things up with the other collaborator's Gemfile.lock? Is there something the other collaborator could have done differently, so that they did not cause any gems to update (rather, just to download the gems specified in the existing Gemfile.lock)? What are the best practices around this situation?

Answer 1

Gemfile.lock should be version controlled. You should be committing any changes to it. When somebody (who you trust) updates it, you should run bundle install to install the gems currently locked in Gemfile.lock.

Just running bundle install will not update an existing Gemfile.lock. To do so, you need to run bundle update.

All that said, there are no actual changes to the versions in your Gemfile.lock. All that changed was the order of arguments for a few lines. You can safely merge those changes in or disregard them; the resulting Gemfile.lock will be (functionally) identical.