0

I am trying to get rid of my "Changes not staged for commit", and my Gemfile.lock keeps re-appearing as an unstaged file. I believe this is because I updated bundler, because the changes are:

- 
- BUNDLED WITH
-    1.10.5

First, these did not work, because Gemfile.lock would update itself: 

git checkout -- Gemfile.lock

git stash save --keep-index --include-untracked
git stash drop

git reset HEAD

git clean -df
git checkout -- .

What worked was:

git update-index --assume-unchanged Gemfile.lock

Looks okay, running "git status":

On branch develop
Your branch is up-to-date with 'origin/develop'.
nothing to commit, working directory clean

I cannot run "git checkout origin/existing_branch"

error: Your local changes to the following files would be overwritten by checkout:
    Gemfile.lock
Please, commit your changes or stash them before you can switch branches.

What is the best practice with Gemfile.lock? How can I pull new branches from a remote while ignoring it?

Charlie Getzen
  • 75
  • 2
  • 7
  • 1
    Going off of [this](http://stackoverflow.com/questions/4151495/should-gemfile-lock-be-included-in-gitignore), I was under the impression it was good to keep Gemfile.lock out of .gitignore. Additionally, this project was created and maintained way before I was hired, I'm sure they wouldn't appreciate me changing the .gitignore :( – Charlie Getzen Aug 24 '15 at 15:30
  • There's no harm in adding it to the .gitignore if it's not checked into the repository. You can always remove it from the .gitignore down the line without any issues. – Catherine Cai Aug 24 '15 at 15:46

1 Answers1

9

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

sjagr
  • 15,983
  • 5
  • 40
  • 67