This post is part of my Git for Writers series, which I started posting as an accompaniment to my Git Started: Git for Agile Writers workshop at the STC 2015 Summit in Columbus, OH. These posts expand on some of the ideas I presented, since you can’t cram everything on such a large subject into one 45-minute workshop.

**For some more of the reasons why I think writers need Git, read this post.**

Git uses configuration files to determine most of its settings. Making changes to these settings — or even knowing that they’re there — can be a little challenging for new users, since, unless you’re receiving an error message, Git doesn’t do much to remind you of these files. It does, however, have a command to help you edit your configuration without the need to know which file a particular setting is in.

The first time you use Git, you do need to set up your identity. Git’s website already has documentation on this, so I won’t reproduce it. (I will point out, though, that you don’t actually have to set up a default editor, especially if you prefer Vim anyway.)

What you need to know about the config files…

Git uses several different config files:

  • Two user config files, one of which (~/.gitconfig) is often called the global config file.
  • A repository-specific configuration file.
  • A system-wide config file.

Most of the time, as the name suggests, you’ll need to be making changes to the global config file. Since Git offers a command to edit configuration settings, though, it’s a good idea to use those commands whenever you make changes, and only access the global config file if you need to see what your settings already are.

Looking at the global config file.

Your global config file might be fairly simple, if you haven’t done much in Git yet and haven’t needed to configure many settings:

Screen Shot 2015-07-10 at 11.46.54 AM

If you use Git often, though, and have taken the time to make more customizations, you might have something like this:

Screen Shot 2015-07-10 at 11.49.10 AM



If you make one customization to your Git configuration, make it adding aliases. They will save your sanity, and a little bit of typing time that adds up. If you’re lucky and working with a team of developers, they might even be able to send you over their alias lists, already pre-tailored to your project’s workflow.

When you use an alias, it’s simply creating a shortcut. For example, because my global config file includes “co = checkout” in the [alias] section, I get the same thing when I enter “git co branch” as when I enter “git checkout branch”. Any flags or options that you want to add work exactly the same.