At this point, the majority of developers are using some sort of version control (or at least I hope they are). It’s widely used for a reason – it helps save our butts on a regular basis.

Modern version control systems like git allow us to roll back uncommitted changes or check out previous commits, which let us try approaches to problem solving that are much harder without that safety net (provided we commit frequently). They let us have multiple people working on the same program at once with less of a risk of people stepping on each other’s toes. They even help us with deployment strategies.

What if I told you they can help you do a lot more than just that?

For me, git has become kind of like Frank’s Red Hot Sauce – I use that shit on everything.

Seriously. I obviously use it for source control, but I also use it for the majority of my writing, for maintaining workshops and talks that I create, and a myriad of other purposes. Leveraged properly, it can be an amazing tool with the added bonus of giving you an off-site backup of whatever you keep in it.

All of the writing for this site is kept in source control. Just like with my code, I make regular commits with (generally) meaningful commit messages. This allows me to keep multiple pieces of writing in flight at once as well as lets me edit my drafts without any worries – if I don’t like how an edit comes out (if it feels clumsy, for example), I just revert my changes.

Workshops and talks are another place where I leverage git, for many of the same reasons that I use it for my writing – it lets me try different approaches to things. If I need to make changes for a specific presentation, I can just make a branch off of main and make the changes there. If I decide I want to make them part of my base talk, I can just merge them back in. No pressure.

Where it really shines, though, is in keeping my resume up to date.

I edit my resume fairly regularly, and sometimes those edits are significant. With source control, just like with my regular writing, I can make changes without worrying because I can always revert back to a previous version. Even better, if I want to tailor my resume for a specific company or job (or to accentuate a specific type of experience that I have), I can just make a branch and do the edits there.

I name the branch after the position or company and drop in a text copy of all of the artifacts for that position (description, correspondence, etc). It helps me keep things organized and lets me refer back to older copies if I talk to the same company at a later date.

Version control systems like git have honestly become one of my most used tools for coordinating and editing non-code work. Hopefully this has given you food for thought on how to leverage it (and possibly other tools that you already use) outside of your normal coding practices.