November 13, 2014

Git Beyond the Basics: Version the Ignore File

Git at Scale
Version Control

This is part 1 of a 6-part series on Git commands.

The development of intellectual property typically features processes that generate “artifacts”, meaning files important for development that shouldn’t themselves be versioned. In software, for example, this can include precompiled headers, object code, library files, etc. Like many version control systems, Git has an “ignore file” feature. That is, if a file named .gitignore is found in the local folder, its contents will be used to determine which files/folders to ignore when executing Git commands.

What many don’t realize is that it’s possible to add the ignore file to the repository. It may seem a little counterintuitive to version a file whose name is deliberately chosen to be ignored, but there’s a method to the madness. Including it in your repository, so that all developers on the project get it, has several important benefits:

  1. It improves the “signal to noise ratio” for any Git command.
  2. It spares every developer the burden of reinventing the ignore-file wheel.
  3. It avoids embarrassing (potentially costly) commits of things that shouldn’t be versioned.

In short, it’s a good practice to develop an ignore file for every project, custom-tailored as needed to the types of artifacts involved. So let’s take a look at a simple ignore file:

# This is an example of a comment, whereas blank lines are ignored.

An ignore file with those contents will ignore files ending with the *.obj and *.lib extensions, excepting a file named MySpecialCode.obj as indicated by the exclamation point at the beginning of the line. Git processes the contents of the file one line at a time, so it’s possible to develop quite precise matching rules with a little effort. Those interested in the details should take a look at the Git Book documentation for the ignore file.


Learn more about Git vs. Perforce >>


Check out our Git solution >>