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?
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.