Version control for manuscripts: what researchers actually need from “track changes”

Every research team runs version control. Most of them just run it by hand. A folder listing that reads manuscript_v3_MR_edits_FINAL_v2_submitted_ACTUAL.docx is a version-control system — one with no diffs, no merge safety, no attribution, and a naming scheme that has already failed by the time the word FINAL appears twice. The instinct behind it is exactly right: writing a paper produces states worth preserving, comparing, and returning to. The tooling is what failed.

Software engineering solved this problem so thoroughly that “version control” barely registers as a topic there anymore. But manuscripts are not source code, and the answer is not to hand researchers a git repository. It is to ask what track changes was actually supposed to do, where it falls short, and which ideas from software version control survive translation into scholarly writing — and which should be left behind.

What track changes was built for — and what broke

Track changes is a fine tool for its original job: one editor marking up one author’s document, once. Its assumptions show immediately under modern co-authoring load. The markup is transient — the moment changes are accepted, the history evaporates, and the question “what did this paragraph say when we submitted?” becomes unanswerable. It is per-copy, so the true history of the paper is smeared across every attachment ever emailed, and reconciling two annotated copies is a manual, error-prone merge performed by the unluckiest co-author. And it records only keystrokes, not intent: five hundred red insertions tell you nothing about whether the argument changed.

Concretely, the failure modes every research team recognizes:

• Lost states. No durable record of the submitted version, the revised version, or anything in between — only whichever files someone thought to keep.
• Fork chaos. Parallel edits on emailed copies produce divergent documents with no principled way to merge them.
• Vanishing attribution. Accept-all erases who contributed what, just when authorship questions become most delicate.
• Noise instead of meaning. Character-level markup buries the one change that matters — a weakened claim, a swapped citation — under a thousand comma edits.

Four ideas worth stealing from software

First: history as a first-class object. In software, every state of the codebase is preserved and addressable; history is not a courtesy, it is the substrate. Manuscripts deserve the same: continuous, automatic capture of the document’s states, with no reliance on anyone remembering to “save as.” The baseline question — what did the paper say at time T? — should always be answerable, cheaply.

Second: named versions, like releases. Software teams do not ship “whatever the code was on Tuesday”; they cut releases — named, immutable points with meaning attached. Manuscripts have natural release points: preregistration, submitted-v1, R1-resubmission, accepted, proofs. A named version is a commitment you can cite, diff against, and return to. It is also the honest answer to journals and integrity processes that ask what, exactly, reviewers were shown.

Third: diffs at the level of meaning. The power of a software diff is that it answers “what changed?” precisely and completely. But a useful manuscript diff must operate on the document’s real units — paragraphs, claims, citations, figures, tables — not raw characters. “§4.2: effect-size claim softened; supporting citation replaced; Table 3 recomputed” is a diff a co-author can review and a response-to-reviewers letter can be written from. In fact, the revision letter is the diff between two named versions, annotated with reasons — teams that adopt this stop reconstructing their own revisions from memory.

Fourth: review as a recorded state. Software changes are proposed, reviewed, and explicitly accepted — and the record of who approved what persists. The scholarly equivalent: suggestions that a section owner accepts or declines, and section review states (submitted for review → approved) that make senior sign-off a fact rather than a recollection. Combined with durable per-contribution attribution — ideally ORCID-linked — this quietly resolves most authorship-credit disputes before they start, and gives CRediT statements something to be generated from.

What not to copy

Translation requires taste, and three beloved features of software version control should not survive the trip. Manual commits: asking writers to decide when to commit imports a discipline burden writing does not need — capture should be automatic, with naming reserved for milestones. Branching and merge conflicts: git branches exist because programmers edit asynchronously and reconcile later; real-time collaborative editing dissolves the problem at the source — everyone works on one living document, and “which copy is canonical?” stops being a question. Divergence should be rare and deliberate (an alternative framing for a different venue), not the daily texture of collaboration. And the interface itself: no researcher should meet a detached HEAD on the way to a results section. The concepts earn their keep; the ergonomics of a 2005 command-line tool do not.

A caution on partial adoption: teams sometimes bolt a git repository onto their existing Word workflow — committing exported .docx files nightly — and conclude that version control does not help writers. It does not help that way, because binary documents defeat the diff, the merge, and the blame all at once; what remains is an elaborate backup system. The lesson is not that manuscripts resist version control but that version control must operate on the manuscript’s native structure. Half a translation is worse than none, because it costs the discipline without paying the insight.

What this looks like in practice

Put together, the requirements list for manuscript version control is short and demanding. One living document as the single source of truth, edited collaboratively in real time. Automatic, continuous history underneath it — every state recoverable, nothing depending on human diligence. Named versions at milestones, immutable once cut. Diffs between any two states, expressed in the document’s own units: sections, claims, citations, tables. Suggestions and review states that record decisions and decision-makers. Attribution that survives acceptance, linked to persistent researcher identity. And exports that always come from a version, so the DOCX sent to the journal is traceable to an exact state of the manuscript rather than to “the file I had that day.”

This is the model we built into Dissertatio — versions named like releases, block-level diffs, pull-request-style suggestions, ORCID-linked attribution — but the checklist above is deliberately tool-agnostic. However your team writes, you can audit your process against it: if you cannot reproduce the submitted version, diff it against today’s draft, and say who approved the change to the key claim in §4, your version control is running on luck.

“Track changes” was never the wrong idea — it was the right idea at the wrong scale, built for a world of one editor and one file. Research writing outgrew that world. The version-control concepts that carried software through the same transition are sitting there, proven, waiting to be translated with care: keep the history, name the milestones, diff the meaning, record the decisions — and let the merge conflicts stay where they belong, in someone else’s profession.