Honestly, I think writers could benefit more from the collaborative editing model than the git branching model.
When do writers need to branch their stories/articles into two forks? If they do that, why not just copy the document and work on it there? The large bodies of text don't have the filesystem dependence that programs do; it doesn't matter what the manuscript is called if nothing #include s it or require()s it.
Instead, it can be quite valuable to have a collaborative text editor: your colleagues' changes are shown in real time as they make them. If you go on a plane ride, they're synced when you get more internet access, with conflicts clearly shown and deliminated so you can resolve them simply.
The collaborative editing would be useful in the later phases of a book -- i.e., working with an editor and copyeditor, it's be great to have a really efficient way to review changes made to the actual text (instead of reviewing a hard-copy with hand-written corrections, and then hoping those corrections are accurately hand-merged into the text...).
But for most of the life of a manuscript, it's just the author working completely solo (from what I've seen). In the standard flow, there's no editor until the book (in a fairly complete and polished draft) is sold to a publisher. A literary agent may read drafts along the way, but normally wouldn't touch the text, just write up higher-level feedback.
On the other hand, the task of designing a narrative that flows well at the scope of a novel is really hard, and can take a lot of large-scale trial and error to improve. She usually does have several "branches" of her current project, as well as large chunks that she has cut from the current draft but doesn't discard (and sometimes may be re-added).
Her first published novel shed more than 300 pages that were never re-added on its way to the final version... it's hard to keep track of all that. It wasn't like "drop this chapter", generally, more like "remove this subplot from the hundred or so places it shows up".
I'm not sure how well the git model would address the problems -- the big problem is scale, and visualizing large structures made up of lots and lots of tiny little words. They are plenty of pain points worth attacking, though, except that most writers don't have much cash to spend on tools.
For something like that you would need a way to mark parts of text, that deal with certain subplots/plots. Like different colors for different plots, but what happens, when they intersect? Or you could use flags, or something like that.
An easy way to trace a plot throughout the novel. Interestingly, a tool, that enables this could even be used by literature students, when analyzing texts for an interpretation (been there, studied that). The only problem with this is copyright and the inability to get your hands on a digital os-/reader-independent format, to work with in the first place.
I worked mostly with texts from medieval times and it was a pain to get hold of (good) digital versions. May be, that this is because language processing approaches are not that widely used in my former field of study.
So to wrap it up - a great tool, enabling authors with this could enable also a better understanding of novels for literature students alike.
When do writers need to branch their stories/articles into two forks? If they do that, why not just copy the document and work on it there? The large bodies of text don't have the filesystem dependence that programs do; it doesn't matter what the manuscript is called if nothing #include s it or require()s it.
Instead, it can be quite valuable to have a collaborative text editor: your colleagues' changes are shown in real time as they make them. If you go on a plane ride, they're synced when you get more internet access, with conflicts clearly shown and deliminated so you can resolve them simply.