I spend my days writing. In my day job, I write emails, I write code, I write requirements documents. Outside my day job I write stories, and articles, and blog posts. Whether I am writing code, or writing a blog post, the result is something to which I can point and say, “Hey, I made that!”
For a few months now, I have been fascinated by the idea of tracking the lifecycle of my work products. I can do this because all of my work products are essentially digital, and essentially plain text. When I write code, the files containing the code are just text files. When I write blog posts, stories, or articles, the files that containing the posts, stories, and articles are, at their heart, text files. This means that at the most basic level, all of the things I make are the same format. The text within the files may include markup, like HTML, or RTF, but they are all readable with simple text editors.
I have frequently used Git to track the things I make at the day job, but for a long time, my Git checkins were limited to just code. Recently, I have started to use Git to track other things I made, like requirements documents, and specifications. In my writing, I used Google Docs for a long time. When my 825 consecutive day writing streak came to an end, I decided I wanted a change, and moved back to Scrivener. At its heart, the text I write in Scrivener is stored as RTF files. I have been using GitHub to track my work on these things.
I like GitHub because it provides a single place to track everything I make. Like most revision control systems, GitHub captures just the changes between checkins, which is efficient. It also makes it easy to see how the things I write evolve over time. I can look at an initial draft of blog post and easily compare it to the final draft by running a command. I can see any intermediary steps. I can see what text I decided to delete or what words I decided to change, or add at the last minute.
Using GitHub with Scrivener
Experimenting, I decided to see how well GitHub would work with Scrivener. At its core, the main writing files within a Scrivener package (a .scriv file) are rich-text format files. I created a Scrivener project for my blog. Each post I write is a new file within the Scrivener project
When I complete a draft, I check it in to GitHub. I am a command-line person and so I use Git commands to perform the check-in, but there are GUI tools available for this as well. For instance, for this post:
The short comment lets me know what I was working on. If I want to see what I worked on in a particular day, I can look at the Git log for the project. If I want to see what I’d done since yesterday, for instance:
By default, all GitHub repositories are public. In order to keep these things private until I am ready to publish them, I have a paid GitHub account which gives me access to private repositories. Private repositories are not necessary for everyone, but as someone who writes fiction and nonfiction for other markets, it is important that my work has not been previously published elsewhere. That includes previously published on the web. Private repos ensure that my writing is not published until I am ready to publish it.
All of my “work products” are now captured the same way, and that makes it easy to track what I make. And because all I really care about are the text files that Scrivener produces, I have created a .gitignore file that ignores other types of files in a Scrivener project. You can find a gist of my .gitignore file for Scrivener here.
One nice thing about my Google Docs Writing Tracker was that it automated the process of tracking my daily word counts, streaks and other statistics about my writing. I am working on a similar tool that does for Scrivener what my Google Docs Writing Tracker does for Google Docs—except it uses my GitHub repos as the source of data. I’m still in the early stages of this, but I’ll post more when I have something that works consistently.
I am hoping that by the end of 2016, I’ll have an automated report that I can point people to that will summarize everything I made in 2016, along with all of the interesting stats. I can do this because everything related to my writing now goes into GitHub.
Leave a Reply to Jamie Todd RubinCancel reply