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?

Solution

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.

Comments

[ianpetzer]

Having your Gemfile.lock under version control is considered the best practice. This ensures that the same bundle of dependencies will be built wherever you install your application, whether it is another developer working on the source code, or the bundle for your production server.

[hammady]

make sure you both use the same bundler version so that the generated Gemfile.lock looks the same and not generate things differently which would be a false alarm commit