Keeping track of old versions of your work is one of those things you don’t appreciate until you have it. Most people keep old versions with a mishmash of file names (novel.doc, novel-backup.doc, novel-backup2.doc, novel-backup-september-2015.doc, …) or using a service like Google Drive or Dropbox. These solutions work but to say they’re lacking is an understatement. Enter git.
Git is a piece of software used to track history of source code. While it’s fine-tuned for this behavior it’s still phenomenal at tracking changes in projects that are structured similar to software. If your project has the following properties git makes an excellent choice:
- work is stored in plain text (i.e., non-binary files)
- files are small to medium-sized
- files are human-readable
Since I use LaTeX all these conditions are met (most word processors have an option to store contents in flat files which gets you most of the way here).
So how useful is git? Think about the backups spread across different services and folders with God-only-knows what names. Count how many you have and compare it to the history of my project.
$ git log --oneline | wc -l 177
177 versions at the time of this post, all of which are time-stamped with metadata about what actually changed. The last two commits look like this:
commit 42bf73d45dfe7fea13996ef9e3b2cdd0e122dc0a Author: K.P. Wayne Date: Sun Jan 29 20:02:52 2017 -0700 Polish up first part of chapter 1 using Pro Writing Aid commit 297b676edc97643f901be6f6d0f846546534f2d5 Author: K.P. Wayne Date: Sun Jan 29 18:54:26 2017 -0700 Work in feedback from Scribophile
Not only is backing up offsite trivial, but each backup contains the entire history of the project. As of right now my entire repository, meaning the full history of my project, is a whopping 652 kilobytes; less than half the space of a floppy disk.
You can also mark specific versions with symbolic names (the git term for this is a tag). This makes it trivial to see what changed between two different versions.
In fairness git has a learning curve and last time I checked most gui tools ranged from awful to bad (coworkers assure me this has changed). A simpler option is mercurial and Joel Spolsky put together a simple tutorial for anybody unfamiliar with version control.
It’s not for everybody and I haven’t tested git with popular tools Scrivener but if it fits in your workflow give it a go.