Version history is the record of what a piece of writing used to be. Programmers have relied on it for decades; most novelists still work without one, or with a folder of files called chapter-7-final, chapter-7-final-v2 and chapter-7-ACTUAL-final. That folder is an attempt at the right idea. A book changes shape many times on its way to being finished, and a writer who can see and return to earlier shapes revises more boldly, and more accurately, than one who can't. This guide covers why that is, how to work with checkpoints in practice, and where branching ideas fit.
Why a novel needs a memory of itself
A short story can live in your head. A novel can't. Somewhere around the second act, a book becomes too large to hold all at once, and from then on every revision is made partly blind: you change a scene in chapter fourteen without being able to see, in the same moment, what chapter six promised about it.
Version history gives the book a memory outside your own. It lets you answer questions that otherwise depend on recollection. What did this chapter say before I moved the reveal? When did the mentor stop being the traitor? Which draft of the opening had the line my critique partner loved? Without a record, those answers are guesses, and guesses about your own book are surprisingly often wrong.
The memory matters most for the parts of a novel that are spread out. A change to one character's motive can ripple across twenty chapters. Being able to look at the book as it stood before the change is how you check that the ripple went where you meant it to, and how you keep continuity from slipping as the draft grows.
The fear that stops big revisions
The most expensive thing a missing history costs you is nerve. Most writers know the feeling of looking at a structural problem - the midpoint lands too late, a subplot is dead weight, the book should open a chapter earlier - and choosing not to fix it, because fixing it means tearing up chapters that already work, and if the fix fails there is no way back.
So the revision shrinks to something safe. The sentences get polished while the structure stays as it is. A lot of books that feel almost right are stuck exactly there.
A checkpoint changes the arithmetic. If the current state of the book is saved and dated, the big change stops being a gamble. You can cut the subplot, move the reveal, merge two characters into one, and read the result honestly, knowing the earlier version is still there to compare against and to take pieces back from. A writer with a reliable history can afford to try more, and the trying is where structural problems get solved.
Checkpoints at the moments that matter
A checkpoint is a deliberate save: a named, dated snapshot of the book or of the chapters you have changed, taken at a moment you choose. Automatic history that records every keystroke has its uses, but checkpoints are what you will actually navigate by, because each one marks a state you meant to keep.
The moments worth a checkpoint are the ones before a decision you might regret:
- Before a structural change. Moving, merging or cutting chapters, changing the order of events, rewriting the ending.
- Before handing the draft to someone. A beta reader, an editor or a critique group will respond to a specific version, and you will want to see exactly what they read when their notes arrive.
- At the end of a draft. Finishing a full pass is a milestone; saving it gives you a fixed point to measure the next pass against.
- Before letting a tool rewrite something. Any time software, an editor or an AI is about to change text in bulk.
Name each checkpoint for what is about to happen rather than for the date, which the record keeps anyway. "Before cutting the Lisbon subplot" will mean something to you in three months. "Saturday" will not.
Reading what a chapter used to be
The second use of version history is quieter and, day to day, more common: going back to read.
Revision loses things. A chapter rewritten four times can drop the one image that made its first draft work, or a line of dialogue that set up something two hundred pages later. Opening the earlier version side by side with the current one is how you find what fell out. Often the answer is to carry a paragraph forward into the new draft rather than undo the whole revision.
It also helps with the plan as much as the prose. If you outline - if your chapters are built from story beats, the small units where something happens and something changes - an earlier version of a chapter shows you what it was meant to do as well as how it was written. Comparing the beats of two versions tells you whether a revision changed the story or only the sentences, which is a useful thing to know when a chapter suddenly reads differently and you can't say why.
Where branching fits
Branching is the next idea along. Rather than a single line of versions, a branch lets you take the book in an alternate direction - the version where the sister is the traitor, the version told from the antagonist's side - and develop it alongside the main one, then keep whichever works better.
For a novelist, branching is most useful for questions too big to settle by thinking about them. You can argue with yourself for weeks over whether a book should open with the murder or the morning before it, or you can write both openings and read them. If your tools don't give you branches, a checkpoint plus a copy does most of the same work: save the current state, try the alternative, and compare.
Branching does ask for discipline. Every branch is a second version of part of your book, and two versions of the same story drift apart quickly. Keep branches short-lived and focused on one question, decide, and either keep the branch or let it go.
Version history when AI is in the loop
Writing with AI makes all of this more important, because AI changes text in larger, faster strokes than a person does. An assistant can rewrite a chapter, reorganize a sequence of scenes or update a character across a book in seconds, and a change that broad is hard to judge without being able to see what was there before.
The habits are the same, applied more often: checkpoint before you ask for a bulk change, read the old and new versions against each other, and keep the parts of each that serve the book. A history that records which changes came from you and which from the AI is also, as a side effect, a record of your own authorship.
How Novelmint handles each of these
Novelmint keeps this history inside the book itself, and each habit above has a place to happen.
Checkpoints. Save checkpoint, in the header of the Timeline (the plan of the book, chapter by chapter and beat by beat), saves a new version of every chapter you changed since its last one. Each chapter keeps its own list, so an untouched chapter is not copied again. Save one before you rebuild a chapter and the plan the new draft came from stays on file.
Reading what a chapter used to be. The Versions button on a chapter lists its history, newest first, with the date, the word count and how each version was saved. View opens one with three tabs: Structure, with the beats and their plot threads; Beats, the plan as written; and Prose, the text built from that version. That is the side-by-side reading this guide describes: compare the beats to see whether the story changed, then copy back the paragraph that fell out.
Branching. Open a chapter and press Branch from here, and the book gets a private copy of its plan from that chapter to the end: the beats, the plot threads and the story bible. The chapters before it stay shared with the main book. Build the branch, read it, and switch between the two from the pill beside the readiness bar. If the branch wins, Make this Main swaps the two versions, prose included, after saving both to version history, and today's version stays behind as a branch you can switch back to. Nothing is merged, so nothing has to be untangled. Free plans get one branch per book and paid plans three.
AI in the loop. Minty, the editor built into the Studio, can add, edit, move and delete beats, chapters, characters and plot threads when you ask her to. Undo last change, in her panel, reverses her most recent round and leaves alone anything you changed afterwards; press it again to step further back, and a beat she deleted comes back with its prose. Every deleted beat and chapter is archived before it goes, whoever deleted it. You can ask Minty who changed a chapter, and she checks the book's record of recent changes and tells you which edits were yours and which an AI made - the same record that shows how much of the book is yours.
Restoring a whole checkpoint in one step is still on the roadmap; today you open the version and take back what you want. The version history page covers it in more detail. Whatever you write in, keep a history you trust, and the large revisions your book needs become ones you can afford to try.