Use a scratch branch in git

git is the de facto standard for version control in 2020, and has held that position for some time. However, it holds a reputation of being difficult to use, and its toolkit-based design leaves a huge amount of room for different workflows. Here’s one that I’ve found useful recently:

git checkout -b scratch

That’s it! Well, to begin with at least. You’ll probably have to rebase it whenever you pull. But what is this branch for? It’s a general staging area, like a souped up git stash. Stashes are easy to create and apply, but they are also easy to lose and hard to share between computers. With a scratch branch, you can create as many staging commits as you want and push them to other computers if you need to. And once something’s been committed into git, it’s very very hard to lose it unless you are trying to.

What’s this useful for? I had to apply a few tweaks to a work project’s build system to get it to build on NixOS, and I’m not sure if they are more generally applicable. But I want to keep them around for my personal use, so into my scratch branch they go. If later on I want to share them with my co-workers, I can just git rebase -i to tidy them up a bit, merge them into the main branch and push. Or I can just leave them there forever. It doesn’t matter!

Stuff that’s only relevant to your own idiosyncratic setup shouldn’t be left sitting there uncommitted, at risk of causing merge conflicts or accidentally being squashed by a checkout: put it safely into your scratch branch and you can keep track of it with the full power of git as you need to. You can even have multiple scratch branches! Lightweight branches¹ are one of git’s most revolutionary features, and it’s easy to forget that you can use them in such a way.