Just that: What do you need version control for?

I've never had the feeling I needed to undo any changes in my (fiction or academic) writing. So what is version control good for? How do you write that you need it? (I am not asking about backups, which I make.)

Inspired by this question: Do You Use Any Version Controlling Software/Methods As Writers?

  • 7
    "I've never had a feeling my house would burn down. Why would I pay for an insurance?"
    – Mat
    Commented Mar 3, 2014 at 20:48
  • 5
    @Mat, what you are talking about is backup. I do backup my writing. What I am talking about is deconstructing the house and rebuilding it differently.
    – user5645
    Commented Mar 3, 2014 at 21:12
  • 2
    A lot of it is down to how you write. I tend to write stream-of-consciousness style and then rewrite (for shorts at least) and tracking my versions is very useful for this. Also If I'm unsure about how to, for instance, end a story, I can create several versions and A/B test them with my test readers without losing anything or having to create whole new documents.
    – CLockeWork
    Commented Mar 4, 2014 at 9:26
  • 2
    It's just for keeping everything together. Let’s say I write in Word, then print it out and rewrite in a new Word document; I have no easy way to compare, and a clunky file structure, and a growing number of documents. I think version control works well for me because I write in LaTeX, and honestly it's just handy, rather than a game changer. It helps keep all my versions together so I can go back and check old versions, revert to different modules and so on. It's just better than overwriting what you've done. I don't believe in ever deleting anything.
    – CLockeWork
    Commented Mar 4, 2014 at 10:04
  • 2
    I guess I just find it usefull to hold on to those old copies, it's not to say that I'll ever revert to them, just that I may want to refer to them from time to time.
    – CLockeWork
    Commented Mar 4, 2014 at 10:04

7 Answers 7


If you are one of those rare people who can write, straight through, without any major refactorings or changes of direction along the way, more power to you. But for many people, and IMO any long-running project, source control is a major benefit. Here are some of the reasons:

  • When you realize the path you're going down is a bad idea, you can roll back to a prior version (not necessarily the most-recent save). Sure, you could save a bunch of numbered/timestamped files to simulate this, but then you are spending your own mental energy on something that the tool can just do for you. Would you rather be writing or doing administrative tasks?

  • Manual "version control" (the numbered-files approach) encourages you to work in one large document (easier to manage). But often you are better off breaking your document down into separate files and creating a master document that includes them all. (And don't forget about any graphics you're including, like diagrams or screen shots; those are files too.) Automated version control makes this no harder than working with one file, but manual "version control" does so you probably won't break it down.

  • Source control lets you intentionally branch files to try out a change. If you don't like it, abandon the branch. This is subtly different from rolling back to prior versions; with branching you can focus on one change (remove this character from the novel, replace the running example in the manual, whatever). Rollbacks are usually after-the-fact realizations and you'll lose whatever other work you were doing at the same time; branching helps you to be more intentional.

  • Branching allows you to work on changes independently. If you tend to have a lot of idea in play at once, or you have only short bursts of time to work on your document, or you're just very distractable and want to "do all the things" now, source control can help you separate those tasks so you don't end up with half of idea 1 and a third of idea 2 and the bare outline of idea 3 all mixed up together in a document that you now need to untangle because your editor wants a snapshot.

  • Most source-control systems have the concept of a label, so you can easily annotate the files for important events like "submitted for first review" or "delivered draft to customer" or "release 3.1". Trust me, if you work on long-running projects, eventually somebody is going to ask you for a copy of exactly what was sent to such-and-such customer a year and a half ago. If you dropped a label at the time, you can do that without having had to archive a copy of everything.

  • If you will ever be working with co-authors, or editors who want to directly edit your source documents, source control is essential to avoid collisions. That way you can keep working and later you can merge in your co-author's additions or your editor's changes.1 (Merging can get messy depending on the type of change, so there's more to discuss here, but that seems to be getting too far afield of your question.)

  • Source-control systems have built-in comparison tools, so it's easy to see the differences between your current working copy and the last one you checked in, or those between two previous checkins, so long as you use a suitable format.1 This helps to remind you of what you changed in this "session", and if you're doing something like addressing review comments, you can compare the comments to your diff to make sure you got them all. Similarly, when you're doing something new, like updating a set of screen shots, you can check to see if you got them all.

  • With source-control systems, checkins are (nearly) "free" so you can check in small, granular changes. One thing this does is to limit your risk; if something happens to your current work (cat across the keyboard, misplaced "rm*", etc), you can get back to the last version you checked in. More importantly, though, by reviewing the comments you made on each checkin (do make meaningful checkin comments; it's important), you can easily get a sense of the progression of work, what you've done already, and what remains.

Source control isn't necessarily a win for everybody; I don't bother to use it for blog posts, Stack Exchange answers, short one-off documents, and so on.2 And you have to either use an Internet service or set up your own server (non-trivial for most people). But for many projects, and especially if source control is already available (e.g. for the code) and you just need to opt in, it's well worth using. As a technical writer I insist on it, even if I'm (at the time) the sole writer. I have never regretted that. (Granted that I work in the software field so the issue is just access to the source-control system, not setting one up.)

1 You cannot diff and merge binary formats. This only works if your source is text of some sort, whether that's some XML flavor, HTML, LaTeX, or something like that. Many modern tools can export as XML, but that might not help you -- if your diff tool is sensitive to white space, then each export is likely to change the line wrap so rewriting one sentence could cause the rest of a paragraph to show as different. Check both your writing tool (how it does exports) and your source-control tool (how it handles this kind of variation). I write all my source in a text editor that won't try to "prettify" or format/export for me, and I can merge and review diffs easily.

2 Actually, I did use Git a few times for Stack Exchange posts, because they were joint efforts and this made collaboration easier. So even there, occasionally it's helpful.

  • 1
    I want to add that some of the benefits (like merging) are based on the possibility to show the differences between versions. So you have to use a file format where that is possible. I.e. either no binary formats or only binary formats you have a comparison tool for. Commented Mar 4, 2014 at 8:47
  • 1
    +1, spot on. I use writelatex.com and that provides simple versioning, meaning I can trial different document structures without losing anything.
    – CLockeWork
    Commented Mar 4, 2014 at 9:24
  • @JohnSmithers good point. I've added a note about that (which is something I've commented on here in the past, but had forgotten to include here). Commented Mar 4, 2014 at 15:03
  • 2
    One other useful feature in version control is the ability to add comments to check-ins. It's very handy if your memory is imperfect or you collaborate with multiple authors to know why a particular section of a work was updated. Commented Mar 4, 2014 at 17:06
  • Let me add one more time: You can disable white space changes (at least in the diff tools I know). And it can be a binary format if you have a comparison tool for that. If you use Tortoise for Subversion, then Tortoise can show the differences of Word documents (using the inbuilt mechanisms of MS Word). Commented Mar 5, 2014 at 10:11

The first scenario is check pointing to safe guard against those moments (and I've had them) where you come to realize a section of the document is missing. This happened when accidentally, without me noticing, as well as when one of my kids happened to hit the keyboard and I had a section of text selected.

The other use though is before I'm going to rework something significant. If I'm going to remove a character or change the raison d'etre for a character, and I'm going back and working through it and realize "Crap, this was a bad idea." I just go back to the last version before I made the change. Also having a checkpoint (checked in version) prior to editing or incorporating feedback, etc. these can be quite useful.

Can you do this by just having copies of files? Yes, however, the issue is the following tends to happen (at least to me)

  1. You start having copies all over the place
  2. The reason for the backup, and what was incorporated up to that point, isn't clear.
  3. Only the last one tends to be valuable (so you delete the rest) only to discover the thing you needed was 2 versions before that.

There is no advantage.

Most people in this forum are from a technical background, so they automatically look for technical solutions.

You don't write a book how you write code. When writing code, you dig in, change a line here, add a function there. This can break the whole system, which is why you have version control and testing and continuous integration.

Books, and especially fiction, isn't written like that. Perhaps if you are writing a technical book, it maybe useful, but I'm not sure how. You write your first draft, where you type in everything you have. And then you start a new draft, where you fix any issues you want. And so on, for as many drafts as you want.

With code, you can make hundreds of changes in a week, which become impossible to track, which is why you need version control. Do you really write hundreds of drafts? If not, using version control is an overkill.

I don't agree with Monica's answer. I have never felt the need to "branch" my book. If I want to try something new, I just create a new chapter (which in Scrivener, is as simple as creating a new text page). If I don't like it, I remove it in the next draft. Using Git to "branch" out everytime you have a new idea is an overkill, and not the way most authors work.

More importantly, it looks like forcing the tools of one domain to another, without understanding why those tools are used in the original domain.

Summary: Use version control if you like it, but it is not required; I'll go one step ahead and say its a distraction, another toy that stops you from working.

  • 3
    A little presumptuous perhaps, or at least in so far as to assume that there is a way that books are written. I'm sure many here will have their own ways of writing, I know I do. I write in modules of sections or chapters, kept as separate documents in a LaTeX collection. Version control lets me play around with putting this section before that one, changing dialogue to make it fit better... if you insist on a start to finish, enforced linear writing style you stifle your ability to change anything, and let’s be honest, a story is never perfect first time :)
    – CLockeWork
    Commented Mar 4, 2014 at 10:50
  • 2
    This way sounds more suitable to a typewriter, or even writing longhand, than using a computer. Why should we constrain ourselves to the old methods, when the new tools allow for different, and perhaps better, methods of working? Commented Mar 4, 2014 at 11:53
  • 2
    For the record, Git and Mercurial predate Scrivener, and other version control systems predate them. While version control may be "new" to people outside of programmers, the technology itself is not. That said, while your workflow may be different and doesn't lend itself well to version control with Git, it doesn't mean no one's is. LaTeX and Markdown lend themselves well to it, so those that use those formats can potentially make use of Git. Also, if you're using something like Dropbox to store your files, you're using version control, even if you're not aware of it.
    – Shauna
    Commented Mar 4, 2014 at 16:04
  • 6
    Fiction books might not be written using branches, but there's no reason to dismiss branches for other kinds of books. Technical manuals for software are often stored with the version they address; branches to the software might require updates to the manual for that branch, and merging those changes back to the main trunk later. Essentially, any work that you expect will ever have more than one version released should have version control. It's not just about getting the first edition done, but also the subsequent ones. Commented Mar 4, 2014 at 17:03
  • 2
    Also I strongly disagree with your notion that there is no advantage whatsoever to version control. Have you never looked back at a previous draft? Do you ever keep backups of old versions of your work? If so, then you are using rudimentary version control. Welcome to the club. When you're ready to do more, there are tools to help you do it. Commented Mar 4, 2014 at 17:09

I can think of one reason: If you have a co-writer, it gives you the confidence to revert to a previous form if you don't like their writing. Or combine conflicts if both of you are writing the same section. This is the original purpose of version control in programming.

As I've said in a comment, very often it's best to rewrite back to a previous draft instead of reverting. There are so many advantages to rewriting. Sometimes reverting might make you neglect important recent changes - you'll rarely be able to revert just one chapter after changing all the other chapters.

I use version control only because I'm familiar with it and find it a really fast way to backup things. A full time writer with no experience with version control will probably waste more time than they save.


I write when I can. (Full-time job, family, house, church, etc. takes up most of my time.) Currently working on a book series with a complicated plot, so I often don't write linearly. (Heck, the plot's not even linear!) Once or twice per week I save under a new version number. It's been invaluable, because I've often cut a section (to paste elsewhere), then gotten busy with two dozen minor changes I just noticed, then gotten interrupted, then cut and pasted a phrase, then put that section where I wanted to move it. "What??? Oh crap! I just lost a whole section!" At that point I can undo a half-hour's editing to get my section back, or -- tada! -- go grab it from an earlier version of the saved document.

An important point is to start your numbering at 001. Not 1, and not even 01. You'll be surprised how many versions you generate.

I would love to have software that automatically does the versioning for me, but I just use Word, and in an unsophisticated way (fancy typewriter). [Does anyone know if the lastest Word will automatically version your saves? Answer as comment.]


The principal reason would be to easily collaborate on a document with multiple authors and avoid overwriting each others copy.

It would also help you open up your book to public contributions, corrections and suggestions if you used a social platform such as github.


To me, it's all about the commit message.

WHAT have I achieved in those 6 hours of hair-pulling? Is a mindset that descends on onself after the fifth commit.

Archiving can be done via cp, scp, rsync of many many more. Changing the way you think is more diffucult.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.