December 2013

Gavin Pickin

Git for Dummies - More about GitIgnore and Cleaner Alternatives

Source Control

After yesterdays post on 'Git for Dummies - Using GITIGNORE files to exclude certain files and folders', we got some great feedback from Jim and Peter, which you can read here. Today, we'll talk about their feedback, and explore a little more into GitIgnore and Cleaner Alternatives to the .gitignore file.

If you're new to the series, don't feel like you missed out, you can still go back and read some of the previous posts, where we covered the basics, and we're now getting into more nitty gritty. 

Why you should use Source Control, Not Using Source Control, amazingly you're not aloneInstalling Git on WindowsInstalling Git on Mac OSXInstalling Git on LinuxYour First RepoSetting up your first Remote Repo on BitbucketCreating your SSH Keys for BitbucketHow to set your Default Name and Email in Git, Converting a Project into a Git RepoPushing Code from Dev to Production with Git, and yesterday... Using GitIgnore to exclude and certain files and folders.

To save you some time jumping back to the last post here, I'll just post Jim and Peter's comments here, and we can build on that.

Jim Priest said

Great post. From what I understand you can also have a 'global' ignore file which impacts any git project you interact with.

For example I use Sublime and don't necessarily want my Sublime project files going in the repo. So instead of adding that to each and every project I add it to my global ignore file and don't have to worry about it again.

And Peter followed up with

Having .gitignore files everywhere is ugly.

As Jim says, put globally ignored/excluded files (like .project files) in the global location (located with "git config --global core.excludesfile"), then any project-specific ones go to "{project}/.git/info/exclude" file and it's all out of the way.

I responded on the last post, in short, incase someone reads that article, doesn't want to chase this one down, but I'll go into a lot more detail in this post.

First of all, thanks for the feedback, its nice to have people chipping in, it makes it better for everyone, and we can all learn, especially me. This blog project is to help me share the info I learn along the way, but a way to chronicle my journey so I have a reference for the future too… so all the feedback is great.

Secondly, they are both right. This series, is named Git for Dummies for a reason, I'm trying to make each post very simple (or as best I can), and sometimes I do go into every detail, and yesterdays post was a prime example. I intended to go into more detail in future posts, but while we're on topic, and we have feedback, I'll do that now.

So first… both Jim and Peter referred to a global setting. Peter stated that with the following command, you can ask git where your global excludes file is.

$ git config --global core.excludesfile

In my case, the response looks like this (I am on Mac OSX)


This file allows you to have one great big gitignore file essentially, which allows you to blanket ignore files for every project on your machine. A perfect example, for someone like myself, being on Mac OSX, there are lots of OS files that I don't want included in any of my projects. For example, this might be what I would have in my Global Ignore file


Another option Peter mentioned was a project ignore file. This is obviously useful for ignoring all the files you want to in a particular project, but not affect every repo on your system. This file is located in the .git/info folder, and the file is called "exclude". 


There are a couple of benefits of using these global files

1 - There are not a million .gitignore files everywhere (slight exaggeration of course)

2 - You can have very specific settings for your system, but does not affect every other clone / copy of this repo

There are always pros and cons, and if you read those, you might think of one con right away… number 2 allows you to have very specific settings for your system that does not affect every other clone / copy, which obviously, sometimes you want to make sure that every clone / copy have the same ignore files… especially to remove tmp files, and log files that are normally generated. Its nice to be able to clone a project, and not have to worry about updating your global for a set of rules, that everyone else has in their globals.

So should you use global or local files? 

As always, the answer is, it depends… it depends on the need of the project, and why you are ignoring these files… if you are the only person using a particular editor, that would be an ideal situation for you having your own global or project ignores.

Github has some great resources, and if you want to learn more about ignoring, you can read their article here

In that article, they even mention that to make life easier, they have a special Github repo, for common .gitignore files, based on OS, project / languages including ActionScript, C, C++ CFWheels, Drupal, and Editors including Dreamweaver, Emacs, NotepadPP and a whole lot more.
You can see that repo here 
If you're feeling a little Open Sourcey, you can even commit back some improvements to the repo… share and share alike.

For the full manual page for Git Ignore, you can find all the nuts and bolts here… including the use of * and ** and what the difference is.

Thanks again Jim and Peter for your feedback, and hope these extra details fill in the gaps.
Thanks everyone for reading, and check back soon for more Git for Dummies

See you soon


Blog Search