3 minute read

Note: This post has been recovered from my archive after having been lost due to my brain injury. It was originally posted in my old development blog on August 1st, 2017.


Excluding files for being versioned in Git is easy through the use of the widely known .gitignore file.

This .gitignore file is normally versioned.

That’s clever, because most software sources will generate binaries or intermediate code when being run or compiled. Also, if you’re working in a virtual environment (Python virtualenv, for instance) or with a package manager (npm or RubyGems, for instance), you’ll likely have your project dependencies in a directory inside your repo.

Adding those generated files or directories in .gitignore will benefit everyone involved in the project, because having git ignoring them will prevent people to add those files to the project, so those files will be autogenerated uniquely for each one.

By the way: You can place multiple .gitignore files, inside each directory, to establish directory-specific rules.

So why in the world would we want to exclude files only for us?

Well, there may be several reasons.

First (and this is a very typical case), imagine you have generated files that are specific to your IDE or your OS. Typical examples are .DS_Store files on MacOS, the .idea directory generated by Jetbrains IDEs and *~ backup files created by vim.

Why would someone who uses Atom on Linux want to mess out with those lines on the common .gitignore file? Should we cover there every file name pattern for every IDE/OS/environment in the world? It doesn’t seem a good idea, don’t you think? In addition, you could come up with a conflict with some editor which uses a pattern that matches a file that needs to be versioned.

Second, maybe you want to use a special file or directory in the project to store something, but, the same as before, it’s something other people don’t have to mess out with. Maybe you want to use nvm but not everybody involved in the project is gonna use it. Or, for example, I usually create a directory called .snippets on each project, where I store… well, code snippets, to have them always located.

To ignore these kind of files locally, I’ll explain two different methods:

Method #1: core.excludesFile

To apply this method, create a file named as you want (for example, ~/.gitignore_global) and specify its path in the git global config variable core.excludesFile

This method makes git ignore files in all local repositories. This makes this method ideal for ignoring environment generated files, but maybe not for project-specific files. If you want to ignore some files only for one project, you’d better make use of the second method.

For example, we’re going to create a file ~/.gitignore_global. Please note that, on this context, global means that we’re going to use these exclusions for all our repositories in our machine, but nobody will know it outside of our environment, so in some sense it will be also local.

So, we create the file to ignore, for example, MacOS .DS_Store files and Jetbrains .idea directories. The pattern syntax is the same as the one used with .gitignore:


Now we have to tell git that we want to use that file as excludesFile:

$ git config --global core.excludesFile ~/.gitignore_global

Method #2: .git/info/exclude

This method is also widely documented. In every git repository, we have a special file .git/info/exclude where we can add the patterns we want to exclude locally.

This .git/info/exclude file is unique for each repository. This makes this method ideal for project-specific files or directories. Anyway, we could use a symlink to a file in our home directory, for example.

Again, the same pattern syntax applies:


This way, git won’t alert you about those files having changes on the repo, and nobody will have to know about your .env variables or the Node version you configured on .nvmrc (and you won’t overwrite files on your teammates repos).