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?
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.
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)
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.
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.
