I’ve recently started using Git version control for my writing. Since I don’t know many writers, I have no idea how commonplace this is, but I do know that people have written articles about doing so.
A Brief History
In the beginning, I kept all of my writing in the My Documents folder. When I had a single desktop PC, this worked, but then laptops came around, and I had to keep synchronizing documents between the two devices. Things only got worse over time. I can’t even remember all of the desktops, laptops, netbooks, and file servers that I’ve owned over the years.
Then there are the backups. Oh, backups. It’s possible that all of my old freshman English papers are still saved somewhere on an unlabeled CD-ROM in some box in my closet. Or tucked away into a folder named “Backup” in a forgotten corner of a file server.
In addition to backups, there are also revisions. Writing is an iterative process: starting with a first draft, refined in subsequent drafts, until a final copy is produced. What if I make changes, then decide I liked the previous text better? Or if I just want to see what changed between two versions?
A couple years ago, I installed MediaWiki on one of my servers. This gave me a private wiki site for my writing, and for awhile it worked well. I could write anywhere I had internet access, without worrying whether I had the most recent version. I could look at the history of any page, view differences, even revert.
But… there are motels that don’t have free wi-fi, and places in the country with no 3G coverage. No internet, no writing. There were other petty annoyances. I hated the built-in editor. I struggled with the PHP session timeout, eventually raising it to 86400 seconds. And so on.
Why not use Git? I use it in software development: source code files are just text, just like the rest of my writing. Git can track changes, perform diffs, merge two different versions of a file. And Git stores everything in a local repository, that can be synced with a remote server with a single command.
The articles I linked explain this pretty well, but my workflow is essentially this:
On my server, I set up a repository named writing.git. This is a bare repository, which basically means it’s never edited directly — it’s just for storage.
On my laptop, I’ve installed the Git software and TortoiseGit. After installing TortoiseGit, I _pull_ed the repository from my server. This creates a complete copy of the repository (history and all) on my laptop.
I can create a new story in the local repository folder. I prefer to write in Markdown format, which is just a text format. TortoiseGit extends the context menu in Windows Explorer, so I can add the file to version tracking, and then commit whenever I’ve made changes that I want to keep.
I like to commit early and often. Git enables me to view any commit, see how the document changed from any other commit, and even revert to a particular commit. If a commit is particularly noteworthy, I can even tag it, e.g. as “Final Copy of Document 1”. Or if I want to experiment with a file, I can create a branch and make changes in that branch. If I like the changes, I can merge that branch onto the master, or if I hate the changes, I can delete the branch.
Finally, I can push the local repository back to my server. (Again, with TortoiseGit, this takes only a couple of mouse clicks.)
I’m still working out some of the issues. Git is designed for source code, so it tracks file differences line-by-line. In my text files, this amounts to paragraph-by-paragraph. I would have preferred a separate repository for each story, but this would have been more work on the server side. Still, I’m happy with this system, for now.