Global Gitignore Files Are Cool and So Are You

I wanted to share an organizational habit I've picked up when working within multiple different git repositories - a global .gitignore file.

Setting it up

First, here's the config setup you need to even allow for such a radical concept.

  1. Define the global gitignore file as a global Git configuration:

    git config --global core.excludesfile ~/.gitignore
    

    If you're on OSX, this command will add the following config lines in your ~/.gitconfig file.

    [core]
      excludesfile = /Users/triplegirldad/.gitignore
    
  2. Load that ~/.gitignore file up with whatever you want. It probably doesn't exist as a file yet so you might have to create it first.

Harnessing its incredible power

There are only two lines in my global gitignore file and they are both fairly useful pretty much all the time.

$ cat ~/.gitignore
TODO.md
playground

This 2 line file means that no matter where I am, what project I'm working on, where in the project I'm doing so, I have an easy space to stash notes, thoughts, in progress ideas, spikes, etc.

TODO.md

More often than not, I'm fiddling around with a TODO.md file. Something about writing markdown in your familiar text editor speaks to my soul. It's quick, it's easy, you have all the text editing tricks available to you, and it never does anything you wouldn't expect (looking at you auto-markdown-formatting editors). I use one or two # for headings, I use nested lists, and I ask for nothing more. Nothing more than more TODO.md files that is!

todo-files-everywhere

In practice I tend to just have one TODO.md file per project, right at the top, ready to pull up in a few keystrokes. Which I do often. I pull this doc up if:

  • I'm in a meeting and I just said "oh yeah that's a small thing, I'll knock it out this afternoon".
  • I'm halfway through some feature development and realize I want to make a sweeping refactor elsewhere. Toss some thoughts in the doc, and then get back to the task at hand.
  • It's the end of the day and I have to switch my brain into "feed small children" mode, thus obliterating everything work-related from my short term memory. When I open things up the next day and know exactly what the next thing to dive into was.
  • I'm preparing for a big enough refactor and I can't hold it all in my brain at once. What I'd give to have an interactive 3D playground for brain thoughts, but in the meantime a 2D text file isn't a terrible way to plan out dev work.

playground

Sometimes you need more than some human words in a markdown file to move an idea along. This is where my playground directory comes in. I can load this directory up with code that's related to a given project and keep it out of the git history. Because who doesn't like a place to play around.

I find that this directory is more useful for long running maintenance projects over fast moving greenfield ones. On the maintenance projects, I tend to find myself assembling a pile of scripts and experiments for various situations:

  • The client requests a one-time obscure data export. Whip up some CSV generation code and save that code in the playground directory.
  • The client requests a different obscure data export. Pull up the last time you did something vaguely similar and save yourself the startup time.
  • A batch of data needs to be imported just once. Might as well stash that in the chance that "just once" is actually "just a few times".
  • Kicking the tires on an integration with a third party service.

Some of these playground files end up being useful more times than I can count (eg: the ever-changing user_export.rb script). Some items get promoted into application code, which is always fun. But most files here serve their purpose and then wither away. And that's fine. It's a playground, anything goes.

Wrapping up

Having a personal space for project-specific notes and code has been helpful to me over the years as a developer on multiple projects. If you have your own organizational trick, or just want to brag about how you memorize everything without any markdown files, let me know in the comments below!

Eli Fatsi

Eli uses his mathematics degree from Carnegie Mellon to blur the lines between the digital and physical worlds. He codes for Shure, Volunteers of America, and other clients from our Boulder, CO, office.

More articles by Eli

Sign up for The Viget Newsletter

Nobody likes popups, so we waited until now to recommend our newsletter, a curated periodical featuring thoughts, opinions, and tools for building a better digital world. Read the current issue.