Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Should Gemfile.lock be included in .gitignore?

I'm sort of new to bundler and the files it generates. I have a copy of a git repo from GitHub that is being contributed to by many people so I was surprised to find that bundler created a file that didn't exist in the repo and wasn't in the .gitignore list.

Since I have forked it, I know adding it to the repo won't break anything for the main repo, but if I do a pull request, will it cause a problem?

Should Gemfile.lock be included in the repository?

like image 394
aarona Avatar asked Nov 11 '10 05:11

aarona


People also ask

Should I add Gemfile lock to Git?

You should always include your Gemfile. lock if you are writing an application.

Is Gemfile lock important?

This is important: the Gemfile. lock makes your application a single package of both your own code and the third-party code it ran the last time you know for sure that everything worked.

What is Gemfile lock used for?

The Gemfile. lock allows you to specify the versions of the dependencies that your application needs in the Gemfile , while remembering all of the exact versions of third-party code that your application used when it last worked correctly. By specifying looser dependencies in your Gemfile (such as nokogiri ~> 1.4.

Is Gemfile lock automatically generated?

Gemfile. lock is automatically generated when you run bundle install or bundle update . It should never be edited manually.


2 Answers

The real problem happens when you are working on an open-source Rails app that needs to have a configurable database adapter. I'm developing the Rails 3 branch of Fat Free CRM. My preference is postgres, but we want the default database to be mysql2.

In this case, Gemfile.lock still needs be checked in with the default set of gems, but I need to ignore changes that I have made to it on my machine. To accomplish this, I run:

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

and to reverse:

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

It is also useful to include something like the following code in your Gemfile. This loads the appropriate database adapter gem, based on your database.yml.

# Loads the database adapter gem based on config/database.yml (Default: mysql2) # ----------------------------------------------------------------------------- db_gems = {"mysql2"     => ["mysql2", ">= 0.2.6"],            "postgresql" => ["pg",     ">= 0.9.0"],            "sqlite3"    => ["sqlite3"]} adapter = if File.exists?(db_config = File.join(File.dirname(__FILE__),"config","database.yml"))   db = YAML.load_file(db_config)   # Fetch the first configured adapter from config/database.yml   (db["production"] || db["development"] || db["test"])["adapter"] else   "mysql2" end gem *db_gems[adapter] # ----------------------------------------------------------------------------- 

I can't say if this is an established best practice or not, but it works well for me.

like image 23
ndbroadbent Avatar answered Sep 28 '22 10:09

ndbroadbent


Assuming you're not writing a rubygem, Gemfile.lock should be in your repository. It's used as a snapshot of all your required gems and their dependencies. This way bundler doesn't have to recalculate all the gem dependencies each time you deploy, etc.

From cowboycoded's comment below:

If you are working on a gem, then DO NOT check in your Gemfile.lock. If you are working on a Rails app, then DO check in your Gemfile.lock.

Here's a nice article explaining what the lock file is.

like image 132
rwilliams Avatar answered Sep 28 '22 08:09

rwilliams