Git for Writing

In recent days, I’ve been making good progress on the novel I’ve been working on, off and on, for years. Back in 2017, I “completed” a first draft (the third quarter was still much too rushed, but at least there were no outright missing bits) and since then I’ve been trying to refine it into something actually presentable. One complication I found was that, while working in plain Markdown felt refreshingly efficient for the initial drafting, it became a lot less workable as I re-drafted and re-drafted and needed to go back to find previous versions of different scenes. I have all these subfolders called “2017 Draft”, “2018 Draft”, “2019 Draft”, etc. but even that felt not-very-workable because I’ve had so many disruptions since 2018 that the bulk of the chapters have not really changed since then, while I’ve found myself rewriting the early chapters much more often than once a year. (As an aside, I know this is a problem – no one’s ever finished a novel by re-writing and re-writing the first 10% – but every time I cold-open my novel that’s where I start, and I can’t just let the flaws there go un-fixed…)

I have dabbled in a few different tools, like Novlr or Scrivener, that would’ve offered me proper version control, but all of them ended up feeling unsatisfactory. I just preferred Markdown to rich-text editing – and appreciated the peace of mind of knowing that all my files were plain text saved directly in my filesystem, and completely app-agnostic. I can change Markdown editors on a whim (and have, multiple times!) and don’t have to export/import my story or translate the format in any way, so long as I’m only switching between Markdown editors (and not black-box closed ones like Ulysses).

It was a bit of a conundrum for a little while, how to have my plain Markdown files and proper version control. It’s fortunate that I decided to get back into blogging, because it was this that led me to my solution: Git. Now probably if you’re a programmer this solution was staring you in the face from the beginning, but that’s not my field at all, and even though I’d heard of Git I’d never really looked into it until a few months ago because I thought it was some really complicated shit that only programmers can understand. But I was talking about my website and the things I wanted to do with it with my Dad (who *is* a programmer), and he encouraged me to look into Git, reckoning that it was not that hard. I worked through this tutorial website called Learn Git Branching, and while initially I applied that knowledge to set up Indiekit and automate rebuilds of my Hugo site, I also created a private repository on Github to host my novel files. Just last week I finally transferred my various drafts to that Github repository, and since then, what do you know! I’ve found it so pleasant to work with this set-up, using Typora as my Markdown editor, that I’ve actually been really productive!

There has been one drawback to Github, and it’s that it doesn’t deal with file renames properly. Instead, it acts as if you deleted the old file and created a brand-new one with no history. This is less than ideal for me, because I’ve long been using a number at the start of each file name to make them all appear in order, so I regularly need to rename files and would prefer not to detach them from their histories when I do. I’d also read before I even embarked on this project that Git itself understands renames just fine so long as you don’t substantially rewrite the file at the same time, so I was a bit put out that Github wasn’t handling it. Fortunately, I came across a comment on a Github issue, mentioning that GitLab manages this functionality perfectly well. So, today, I moved that repo across to GitLab (well, duplicated it, technically, for now). I’m just unfamiliar enough with GitLab’s website layout for it to feel uncomfortable for now, but I’m sure I’ll get used to it over time – and I can confirm it handles individual file histories properly 🙂

There are two more major features of Git that I feel are helpful in managing my novel.

The first is tags. I started out by uploading the files from my different drafts over the top of one another, using the tagging system to tag the novel as it was at specific moments in time (i.e. before I forked and started my new subfolder with the next draft). Not only would this be a useful system to mark different drafts, but if you (like me) are prone to major reorganisations of content, it might help to be able to “tag” the last commit pre-reorganisation, so you can go back to it easily if you need to. (That’s if you don’t just branch it, of course, but more on that next paragraph.) Of course, because Git hosts are usually expecting to host software, they tend to correlate “tags” to “releases”… in a writing context, I found this kind of cute 🙂 Like, “Aww, you think I released this story anywhere just because I finished a draft? That’s cute!” But anyway, the point is just that you can find specific points in your project’s history easily.

The second useful feature is branches. As I mentioned, I’ve been somewhat indecisive as to how I even want to structure my book. My original draft had it skipping forwards and back in time, but on a cold reread I thought that made the beginning kind of jumpy, so I thought I’d try reorganising it to make it strictly chronological. I’m not 100% committed to it being strictly chronological, though — skipping back and forth did have some genuine advantages, which is why I wrote it that way in the first place — so I’ve kept these two approaches as two different branches for now — no problem!

Again, Git hosts expect you to use their platform to make software, where if there are different versions, usually you’d create those at the building and packaging stage, not by maintaining different branches in the repository. But there’s no reason you can’t use Git like this. It’s pretty versatile.

So overall, I’m feeling much happier now: I can work iteratively on my novel, secure in the knowledge that a full version history — at the project level *and* the file level — is right there, and that I can edit in whatever light-weight editor, from whatever device, I want. I’ll admit that switching over to GitLab today has made for a bit of a distraction from my recent productivity (and now I’m wondering whether to move my website repositories too, and what to do about the duplicates 😅), but I should now have laid a good foundation for future work. Honestly, I wish I’d thought to look into Git ages ago, because it works so well for what I want to do.