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.
That’s all
I think the tips in the list are not obvious, yet come in handy with daily .git workflow. If you know any fancy command, please leave a comment.