Gemfile.Lock Always Has Changes Not Staged for Commit

Something keeps rewriting my Gemfile.lock

Found the culprit, thanks to this answer (this answer concurs): Spring. There were half a dozen rogue spring processes on my machine, and any or all of them must have been regenerating the file. Killing those processes solved the problem, and so far adding export DISABLE_SPRING=1 to my .bash_profile seems to have kept it from recurring.

(spring stop might have worked too. I don't know whether it stops all Spring processes or just one of them, though.)

How to manage Gemfile.lock with git in rails

Do not add Gemfile.lock to your .gitignore!

This ruins the point of the lock file.

Your Rails app is described by the Gemfile, which uses a loose description of gem versions installed for your app, based on dependencies and soft versions. Because some minor version and dependency upgrades can be breaking, the lock file keeps your app described with specific versions and Git refs down to a specific commit, so that you can achieve a working state of your app when you deploy to dev/testing/production servers and/or share the repo with your peers.

If you do ignore the lock file, any new user or server will just install gems to the latest versions and dependencies as defined/limited by the Gemfile. You will spend hours trying to figure out the "best mix of software that makes your app work locally" when the lock file would have already done that for you.

The better solution is to stop using bundle update unless you're looking to update a gem inside of your Gemfile. You should almost always use bundle install to work off of the lock file - and it will never be changed. This works between branches and git pulls.

However, once you want to update a gem version for your product, you should update the Gemfile, run bundle update <gemname>, and then commit the resulting Gemfile and Gemfile.lock

Finally, if you accidentally ran bundle update and now you have an updated Gemfile.lock, you should just reset the lock file and re-run bundle install

why does bundler keep changing Gemfile.lock with no real change?

I suspect this is related to Bundler version. If you check the changelog, you can read:

"Revert gem source sorting in lock files"

So, if different people with different Bundler versions are commiting to this repo, you probably should use the same version (for example 1.7.2).

You can check your Bundler version with:

bundler -v

Why don't we commit our gemfile.lock for gems?

This article is a bit dated (~6 years old) although it holds merit in the fact that the gemspec will hold the version controlling. If your gem has a dependency on a specific rails version you would add:

s.add_dependency "rails", "3.2"

When a user tries to use your gem on rails > 3.2 the dependency kicks in.

Hope that answers your question. If not, please clarify and I will update this post.

Should Gemfile.lock be included in .gitignore?

Simple answer in the year 2021:
Gemfile.lock should be in the version control also for Rubygems. The accepted answer is now 11 years old.

Some reasoning here (cherry-picked from comments):

@josevalim https://github.com/heartcombo/devise/pull/3147#issuecomment-52193788

The Gemfile.lock should stay in the repository because contributors and developers should be able to fork the project and run it using versions that are guaranteed to work.

@rafaelfranca https://github.com/rails/rails/pull/18951#issuecomment-74888396

I don't think it is a good idea to ignore the lock file even for plugins.
This mean that a "git clone; bundle; rake test" sequence is not guarantee to be passing because one of yours dozens of dependencies were upgraded and made your code break. Also, as @chancancode said, it make a lot harder to bisect.

Also Rails has Gemfile.lock in git:

https://github.com/rails/rails/commit/0ad6d27643057f2eccfe8351409a75a6d1bbb9d0

Bundler: always use latest revision of git branch in Gemfile

This isn't how bundler works.
The point is to allow seamless versioning of dependencies.
(particularly so you know exactly what version of the code is deployed at any given time).

If want the latest version, you should just run.

bundle update magic_beans

This is exactly the same functionality as if you just say

gem "rails"

I'd suggest though, if you have a range of specific things you want to update
then add a custom binary (say an executable file named bundle_update)

#!/usr/bin/env bash
bundle install
bundle update magic_beans

Then just do a ./bundle_update when you want to update these things.

What does Changes not staged for commit mean

when you change a file which is already in the repository, you have to git add it again if you want it to be staged.

This allows you to commit only a subset of the changes you made since the last commit. For example, let's say you have file a, file b and file c. You modify file a and file b but the changes are very different in nature and you don't want all of them to be in one single commit. You issue

git add a
git commit a -m "bugfix, in a"
git add b
git commit b -m "new feature, in b"

As a side note, if you want to commit everything you can just type

git commit -a