My 5 tips for a better git workflow

When it comes to .git, I like to use the command line. So far there is no application appealing to me as much. (Actually, Visual Studio Code has excellent diff preview, but it’s a recent finding for me). Here I share some of tips and tricks I use regularly.

Preview whole commit tree at once

This one shows commits from all branches (--all) as a tree (--graph), --decorate will add branch/tag information:

$ git log --oneline --decorate --graph --all

I have this command aliased as glodga.

Temporary put changes on a side (use stash)

Sometimes I happen to compile, and things break. Then I start wondering if it’s because of my recent changes or because I committed broken code. I don’t want to commit, so I stash my changes:

$ git stash

This command saves current changeset (staged and unstaged) on the additional stack. There are two options for getting back:

$ git stash apply # re-apply changeset
$ git stash pop # re-apply changeset and remove it from stack

What’s the difference? apply will leave changeset on the stack and you can use it later. To interact with stash, use

$ git stash list # a list of changesets
$ git stash clear # removes everything

Reorder commits

We rebase current branch on top of itself. Let’s say I want to reorder last three commits, then the command is:

$ git rebase --interactive HEAD~3

Now I can change the order; squash commits etc. I have never tried to do this on pushed ones 😉

See file history

Sometimes I want to see what commits modified particular file or how it looked at *that* revision. To show changesets that changed a file run:

$ git log --follow -- <file>
$ git log --follow -p -- <file> # will also show made changes

When I find the commit, I check how this file looked in there:

$ git show <revision>:<file>
$ git show b558ac0329a3088a2883ee70f9923b926c722a12:src/main.cpp # example

Use git tags for versioning builds

This one is a novelty for me as well. For Konstruisto, I wanted to have better knowledge of what exact version has the problem, so I can precisely identify the build by screenshot or so. I came with build description like

<major>.<minor>.<patch>-<sha> <debug/release>

The only place where I keep version is git log, I use tags to mark new version:

$ git tag -a v0.0.0 -m "v0.0.0"

And here comes the magic: when building, my makefile fetches last tag name matching pattern:

$ git describe --match "v[0-9]*" --abbrev=0 HEAD

It also takes the shortest non-colliding abbreviation of commit hash:

$ git rev-parse --short HEAD

Final build description of every build looks like this:

BUILD_DESC = $(PROJECT_VERSION)-$(PROJECT_LAST_COMMIT) $(CONFIG)

I make a lot of screenshots, and it helps me to identify changes these are referring to (window title contains the build description string).

Extra: Give your commit a good name

For a long time, I had a problem with consistent commit naming: different approaches worked for some time, but finally I always ended up with a mess. Lastly, I found somewhere a helpful tip: every message should end a sentence This commit will…. It helps to keep names clean and work’s well with any message.

For the message body, I use no convention. Only special cases need further explanation. Usually, I put regular sentences in there.