Safe or Fast, Choose Two
There’s multiple ways to climb. You can climb extremely safe, like on a via ferrata or using a top-rope, play it more on the loose side like Alex Honnold, or anything in between. And there’s good reasons for all types, just be sure you know what you’re doing and what you put at stake.
There’s also multiple ways to code. Play it safe using Git with frequent commits, or disregard history altogether and use nothing but a working tree.
But unlike in climbing, safety in software development, and especially since Git, is almost free, does not constantly get in the way, and always catches you. Using it is a no-brainer.
Commit Often
In Git, commits are basically free, since they only act on your local repository. Indeed, commits are so fast that you could commit every keystroke when developing software, without major ill-effects. Doing so would be quite drastic, and it would have unpleasant side-effects, so please don’t, but committing after every short break, every refactoring, every isolated change, … is totally doable and will by itself be able to safe you a lot of headaches later.
To keep these commits cheap, don’t worry too much about the commit message. It shouldn’t hurt your flow, so just go with it. Messages like ‘wip’, ‘wip2’, ‘asdf’ are not unheard of, and that’s OK. These commits form your safety net, not the story you are telling.
Squash It
There will be times when you’ve finished something, say a big refactoring. Finally everything fits, the compiler is happy, tests are passing again. These are the times when you add a new chapter to your story. The intermediate commits since the last chapter? Just squash them together. You’ve just climbed the hill, no need to leave the ropes behind.
The Meta
All of the above could be seen as general safety advice, and applies - more or less - to other version control systems as well. But there’s more to it - what if something went wrong while using Git itself, and now you’ve lost some important commits?
This is where Git has an ace up its sleeve. Instead of throwing away commits which are not referenced anymore, say by a branch or tag, Git remembers them. To get rid of such commits, which are called unreachable commits, you can expire the reflog and run git gc, with gc being short for garbage collect. Don’t be afraid though, these are not commands that run automatically, at least not on the commandline, and also not by any sane alternative UI. Which means that you can always go back to your commits, even if you lost the pointer to them.
In the Git commandline, this is called ‘reflog’ and you access it using git reflog. In SmartGit, it’s even easier - just select ‘Recyclable Commits’ from the branches view (it’s the last entry), or ‘Reflog’ in the Standard Window, and SmartGit will show you the commits which are not reachable anymore, including their position in your commit graph.
Nice.