Think about the last time you were mountain climbing. You clip your carabiner as you go depending on how far you’re willing to let yourself fall if you slip. So how far apart do you set them if no one is watching? What if you friends are watching? A little farther?
That’s the analogy I got from Rob Richardson the other day at a Meetup on advanced git topics, and it perfectly captured the value of git’s rebase to me.
If you’re not familiar with git rebase, it’s basically a way of revising your source code commit history before you publish it to a place like Github. With it, you can make lots and lots of small local commits — even if your code sucks in any given commit — and then remove or compress certain unsightly commits when you publish.
For an example, you’re working locally on your repo. You’ve committed some changes that worked, some didn’t. Your revision history looks like this:
But when publishing to Github (or behind your firewall to your snarky coworkers), you want to make your revision history cleaner so that the world doesn’t have to see the commits that didn’t work out. Enter git rebase (interactive):
And suddenly (magically, even), those two unfortunate commits disappear when you publish. Snarky coworkers silenced.
Honestly, having this feature might actually change the way I think about coding a bit. All of us have a little anxiety about checking in crappy code, so being able to commit a rosier picture than you had locally takes a little pressure off.
And speaking of anxiety, git is from Linux Torvalds and I presume the kernel community uses it heavily. If I were contributing to the kernel, personally I’d have a ton of anxiety about my revision history. I wonder if that was the inspiration for the feature…?
(For a much better description of how to use git rebase, use this Atlassian tutorial.)