Git Ignore | Alchemists

Git Ignore

When first setting up and configuring Git, you might overlook or not appreciate the value of your Git ignore file. Let’s learn about your Git ignore file both in terms of global and local configuration and what to put in it.

Table of Contents

Configuration
- Global
- Local
Guidelines
Linting
Conclusion

Configuration

Git’s configuration documentation states you can use core.excludesFile to configure where your ignore file is located:

Specifies the pathname to the file that contains patterns to describe paths that are not meant to be tracked, in addition to .gitignore (per-directory) and .git/info/exclude. Defaults to $XDG_CONFIG_HOME/git/ignore. If $XDG_CONFIG_HOME is either not set or empty, $HOME/.config/git/ignore is used instead. See gitignore.

This means, by default, you can define what you want to ignore via the following files:

# Global default as specified by the XDG specification.
$HOME/.config/git/ignore

# Local and unique per project
<your project path>/.gitignore

# Local and unique per project
<your project path>/.git/info/exclude

By default, please put as much as you can into your global Git ignore file so you can define common directories and files in one place while reducing the maintenance burden by using the same configuration across multiple projects. This can ruffle the feathers of inexperienced engineers new to your project because they might complain about multiple files showing up in their Git diff when trying to commit new changes for the first time but this is only an opportunity to educate and train these engineers in the advanced techniques of Git rather than pollute your project’s local Git ignore file. More on this in a moment. For now, let’s talk about your global ignore file and then move on to discussing your per-project local ignore file.

Global

As documented above, the default path of your global Git ignore is going to be located here:

$HOME/.config/git/ignore

The file location adheres to the XDG specification for organizing configuration files. This is a powerful specification. Definitely take the time read more about XDG if you are not familiar. You can also use the XDG gem which allows you to leverage the XDG specification within your own Ruby code. 🎉

Should you not want to use the XDG specification — again, strongly discouraged — you can always specify a custom path via the core.excludesFile setting in your global (or local) Git configuration. As for what to put in your global ignore file, here’s what I use in case it’s of interest:

# Archives
*.7z
*.bzip
*.dmg
*.gz
*.iso
*.jar
*.rar
*.tar
*.tar.gz
*.zip

# Bundler
.bundle

# CTags
.tags
.tags_sorted_by_file
/tags

# Databases
*.dump

# Environments
*.env*

# Logs
*.log

# macOS
.DS_Store

# SimpleCov
coverage

# Processes
Procfile.dev

# Solargraph
.solargraph.yml

# Temp Directories
tmp

The source code for this can be found via my Dotfiles project, specifically my ignore file. Feel free to pilfer anything that might be of use to you.

Local

As for your local ignore configuration, you have two options as stated earlier:

<your project path>/.gitignore
<your project path>/.git/info/exclude

Most projects use .gitignore because it’s safe to commit to your repository and easy for anyone working on the same project to discover what is ignored or add to it.

You can also use .git/info/exclude but anything you add here won’t be shared across the team as a whole. This can be valuable when you want to ignore something that is specific to you and doesn’t effect the team. Extremely handy when needing to use additional tooling that is unique to your workflow but isn’t desired by the rest of the team so you can work at peak performance, unhindered.

As for what to put in your local Git ignore, that definitely depends and will evolve over time. For example, when using Rubysmith to build a new Ruby project, you’ll see the following in your .gitignore:

.bundle
tmp

…but if you opted to build a Ruby gem using Gemsmith, you’d get a slightly different .gitignore:

*.gem
.bundle
Gemfile.lock
pkg
tmp

While the above is specific to Ruby, patterns will differ per programming language used and project requirements. A rule of thumb, especially if repeating yourself, consider extracting what you have defined locally into your global ignore file.

You’ll also notice there is some duplication between this and the the global ignore example shown earlier. This was originally done to appease people new to Ruby projects but will eventually be moved to the global Git ignore configuration to improve multi-project maintenance. If nothing else, this does provide a good example of patterns ripe for deduplication.

Guidelines

With all of the above in mind, here are a few guidelines for you to follow:

Default to the XDG specification.
Extract common patterns to your global ignore file when possible.
When you have specific files or folders unique to you, don’t force ignoring all of these files onto the team. Use your global configuration or even the .git/info/exclude file within the project you are working on itself. This’ll empower you to be productive without adding unnecessary maintenance burden upon the team. A good example of this is IDE specific local folders like Visual Studio Code’s .vscode folder, RubyMine’s .idea folder, etc.

Linting

As of right now, the ability to lint and encourage common patterns isn’t provided via the Git Lint gem — another gem I maintain — but will be thinking about how to improve upon this and encourage better practices. If you have thoughts or ideas, please reach out.

Conclusion

Hopefully this dive into global and local Git ignore files has been of help to you. If you let Git do all of the heavy lifting for you, you’ll be more productive with less of a maintenance burden to boot. Enjoy!