Gemfile.lock and the .gitignore

I don’t know about other people, but when it comes to source control systems, I don’t like putting everything in my repository. That’s why tools like Nuget exist, so we don’t have to waste space in the repository for 3rd party stuff. In svn, putting tons of crap into your repo isn’t that big of a problem as long as you have loads of hard drive space on your svn server. However, anyone familiar with git should already know, when you clone a git repository, you get the whole repository – complete with every revision.

This really makes you think twice about just throwing a 3rd party library in your repository. Sure it may be small now, but you update the 3rd party package a few times and suddenly you’re cloning several hundred MB of 3rd party libraries, and you probably won’t ever look at the old copies ever again.

So when ever I start working with a new IDE, or in a new language/framework, the first thing I Google is “.gitignore <name of framework/language/ide>.” When I started playing with automation was no exception. The part that left me confused was on this whole Gemfile.lock file. As a general rule of thumb, anything generated by an IDE or build tool should be thrown into your .gitignore (or whatever file is applicable for your source control system) without a moment’s hesitation. But looking at the documentation for Bundler it quite clearly says to add the Gemfile.lock to git, including these lines directly in their setup instructions:

This to me was confusing at first. I didn’t know that much about Ruby or Bundler or these Gem thingys, but I assumed the documentation is probably smarter than I am. It was after-all written by the people who make tool I’m using.

Not long after, I was working in iOS using CocoaPods when I finally realized the reason for the Gemfile.lock. CocoaPods has something that serves the same purpose as Gemfile.lock named Podfile.lock (nice naming convention if you ask me). They made the reason for the Podfile.lock a little more apparent in their documentation. (I know that the documentation for Bundler does include what the Gemfile.lock is, but at the time, I didn’t know enough about Bundler to know where to go looking)

Thanks to the Podfile.lock every machine which runs pod install on the hypothetical project will use RestKit 0.10.3 even if a newer version is available. CocoaPods will honour this version unless the dependency is updated on the Podfile or pod update is called. In this way CocoaPods avoids headaches caused by unexpected changes to dependencies.

From their documentation, It’s rather obvious why you’d want this in your repo and not in your .gitignore. If you ignore the lock file, and then you checkout a previous version/branch in you’re repository, you’ll have no way of ensuring that the 3rd party dependencies you compile with, were the same dependencies that you compiles with initially. Additionally, you have no way of ensuring that all of the other developers are using the same versions as you.

This should really be more in your face on the Bundler website so that there are less StackOverflow questions about it.