Git skills

Free Git Configuration Tricks

Let’s talk about Git. Lots of developers use it every day, but unfortunately, not many go beyond the most basic usage. Here, I describe a few cool Git configuration tricks that will help you Git better.

Before we dive right in: These techniques are primarily useful if you are using Git through the Command Line Interface (CLI). Which you definitely should be! There are a lot of good GUIs for Git; however, they can never give you the same mastery as using the CLI directly.

Because we are using the CLI, the configurations I present here are trying to stay as close as possible to the vanilla feeling of Git. I won’t show any fancy do-a-bunch-of-things commands in this post, maybe some other time. The commands here still suppose that we follow a standard workflow. Something like:

> git pull
> git checkout -b [feature]
... do the work, using:
> git add [file]
> git commit -m [message]
... deliver with something like:
> git merge master
> git checkout master
> git merge [feature]
> git push

I try to preserve that feeling. I also suggest using standard abbreviations for the standard commands, like co instead of checkout. However, this is, of course, entirely up to you.

A Nice git log

We cannot work effectively with our eyes closed. The same is true when using Git: We need to see what we are working with. Git has a wonderfully powerful command for inspecting our history: git log. This power is a double-edged sword, because it comes from being configurable through a myriad of flags.

The most straightforward improvement we can make then is to simply alias git log with some flags, and then adjust it once in a while when we discover something smart. If you don’t know where to start for where to start, you can use mine directly:

git config --global alias.sl "log --graph --pretty=oneline --abbrev-commit"

This command gives you this output:

The -6 tells log that we want to see the six latest commits.

Rebase Instead of Merge

In Git, we also like to have a beautiful clean linear history. It is much harder to get an overview of our history if it is filled with branching. Our history can also be polluted by merge commits, which add no real information.

Instead of merging we can rebase. Where merge joins two histories by having them in parallel, rebase joins them by putting one after the other. This is illustrated in this figure:

Merging (left) vs. rebasing (right)

In many cases, they feel similar to use. You can get conflicts when merging, and also when rebasing. We can remove the differences with a little configuration.

On Pull

By default git pull performs a merge. We can change this to use rebase with this command:

git config --global pull.rebase true

In General

We can still use merge for fast-forwarding branches, like the last git merge in the workflow from the beginning. But we need to make sure we don’t accidentally create a merge commit. To this effect, we create a new Git alias for merge that can only fast-forward.

git config --global alias.me "merge --ff-only"

Better Push

One situation where rebasing can feel quite different is that because we are moving history around git push may complain that our histories are unrelated. Therefore we need to use push with the flag --force-with-lease. A force push lets us push whatever we want, but can be dangerous if someone else has worked on a branch we are pushing. The --force-with-lease flag does a force push only if the branch is unchanged. This way, we can never lose any work.

git config --global alias.pu "push --force-with-lease"

Add With Tweezers

We all know that we should write good meaningful messages for our commits. There are several pages with guidelines for how they should look. But sometimes I forget to commit, or do a bit too much work before doing it. If this situation seems familiar to you, then you should consider adding a -p to your git add .. With the -p flag add lets us chose the exact sections to include in a commit.

git config --global alias.ad "add -p"

Finally, no more large commits.

Check The Mirror Before You Go Out

When we deliver something, we are about to publish our part of the history to the entire team, maybe the world, if our software is open source. Most people take a quick peek in a mirror before going out in public. We can do the same in Git by adding -i to the git rebase master.

When we use this flag, Git presents us with the commits we have made, and gives us a bunch of options to manipulate them if we want. Examples include: we can change a commit message or remove a commit entirely. Familiarizing yourself with all the options is well worth the effort.

Summary

After all these changes, our workflow is mostly unchanged, except we use the new aliases we have made:

> git pull
> git checkout -b [feature]
... do the work, using:
> git ad [file]
> git commit -m [message]
... deliver with something like:
> git rebase -i master
> git checkout master
> git me [feature]
> git pu

But magically, our history will be prettier, for free.

If you liked these tricks, you might also like my approach to refactoring, described in my book: