Why a Growing Number of Writers Are Ditching Word Processors for Git and Plain Text

Somewhere between the bloated ribbon bars of Microsoft Word and the austere blinking cursor of a terminal window, a quiet movement has been building. Writers — not software engineers, but people who craft prose for a living or for love — are adopting Git, the version control system built by Linus Torvalds for managing Linux kernel development, to track and manage their manuscripts, articles, and books. They’re pairing it with plain text files, often formatted in Markdown, and walking away from the commercial word processors that have dominated writing workflows for four decades.

It sounds perverse. Git was designed for coordinating thousands of developers working on millions of lines of code. Its command-line interface is notoriously hostile to newcomers. And yet, as a recent detailed guide published by It’s FOSS argues, the tool solves a set of problems that writers have suffered with for years — problems that Word, Google Docs, and Scrivener were never really built to address.

The core argument is simple. Plain text files are eternal. They don’t depend on any company’s proprietary format. A .txt or .md file written today will be readable in fifty years without any special software. That can’t be said of .docx files, which encode content in zipped XML that requires specific applications to render. It certainly can’t be said of whatever format Google Docs uses internally on its servers. Writers who care about the long-term survival of their work — academics, novelists, journalists building archives — have reason to care about this distinction deeply.

But longevity is only part of the pitch.

The real draw is version control itself. Every writer knows the pain of the filename graveyard: thesis_final.docx, thesis_final_v2.docx, thesis_ACTUALLY_final.docx, thesis_final_submitted_revised_FINAL.docx. It’s a system born of desperation, and it fails the moment you need to understand what actually changed between versions. Git eliminates this entirely. Each commit is a snapshot of the entire project at a specific moment, with a message explaining what changed and why. You can move backward and forward through the history of a document with precision, comparing any two versions line by line. The It’s FOSS guide walks through this workflow in detail, showing how a writer can initialize a repository, make commits at meaningful intervals — after completing a chapter draft, say, or before a major structural edit — and use git diff to see exactly what was added, removed, or reworded.

This isn’t theoretical. The workflow has real adherents in serious places. Cory Doctorow, the science fiction novelist and technology commentator, has long kept his manuscripts in version control. Academic researchers working with LaTeX have used Git for years. And the practice appears to be spreading into less technical circles as Markdown gains mainstream recognition and tools like Obsidian, iA Writer, and Typora make plain-text writing more visually appealing without sacrificing the underlying format.

The collaboration angle deserves attention too. Git’s branching model — originally designed so developers could work on features in parallel without breaking the main codebase — maps surprisingly well onto editorial workflows. A writer can create a branch to experiment with restructuring a chapter. If the experiment works, the branch gets merged back. If it doesn’t, it gets discarded. No harm done. No need to maintain six different copies of the same file. The It’s FOSS article emphasizes this point, noting that branching lets writers take creative risks without any danger of losing stable earlier versions of their work.

And when collaboration involves other people — an editor, a co-author, a research assistant — platforms like GitHub and GitLab provide infrastructure for managing contributions. Pull requests, originally a code review mechanism, become editorial review tools. An editor can suggest changes in a branch, the writer can review the diffs, and both parties maintain a clear record of who changed what and when. This is a level of editorial accountability that track changes in Word approximates but never fully achieves, particularly across multiple rounds of revision.

There are, of course, significant barriers.

Git’s learning curve is steep. The command line intimidates most non-technical users, and Git’s terminology — staging area, HEAD, rebase, cherry-pick — reads like jargon from another profession because it is. Graphical Git clients like GitKraken, Sourcetree, and GitHub Desktop lower the barrier somewhat, but they still require understanding the underlying concepts. The It’s FOSS guide acknowledges this directly, positioning its tutorial as a gentle on-ramp for writers willing to invest the time.

Markdown itself presents a smaller but real friction point. While its syntax is minimal — asterisks for emphasis, hash marks for headings, brackets for links — it requires writers to think about formatting in a fundamentally different way than a WYSIWYG word processor demands. You don’t see bold text; you see bold text. For many writers, particularly those who’ve spent decades in Word, this feels like a step backward. It isn’t, but it feels that way, and feelings drive adoption.

There’s also the question of output. Publishers, agents, and most editors still expect .docx files. Academic journals want LaTeX or Word submissions. This means plain-text writers need a conversion step, typically handled by Pandoc, the open-source document converter created by philosopher and programmer John MacFarlane. Pandoc can transform Markdown files into Word documents, PDFs, HTML, ePub, and dozens of other formats. It’s powerful. It’s also another tool to learn and configure.

So why bother? Why add all this complexity to the act of writing?

The answer that keeps surfacing in discussions among writers who’ve made the switch is control. Total, granular, auditable control over their own work. No cloud service holding their documents hostage. No proprietary format that might become unreadable. No opaque revision history buried in a binary file. Every change recorded. Every version recoverable. Every word stored in a format that any text editor on any operating system can open.

Recent conversations on X and in developer-writer communities reflect growing interest in this approach. Discussions around tools like Obsidian — which stores everything as local Markdown files and has spawned a cottage industry of plugins including Git integration — suggest that the appetite for plain-text, version-controlled writing extends well beyond the Linux enthusiast crowd. The Obsidian community has grown rapidly through 2024 and into 2025, with users frequently sharing Git-based backup and sync workflows as alternatives to the app’s paid sync service.

The broader context matters here. Trust in cloud-based productivity tools has eroded somewhat as companies have shifted pricing models, shut down products, or changed terms of service in ways that affect user data. Google’s decision to limit free storage across its services, Microsoft’s aggressive push toward subscription-based Office 365, and periodic outages of cloud platforms have all contributed to a quiet re-evaluation among power users. For writers whose entire professional output lives in documents, the idea of depending on a single vendor’s continued goodwill and solvency carries real risk. Plain text on a local drive, backed up to a private Git repository, eliminates that dependency.

None of this means Microsoft Word is going away. It won’t. The vast majority of professional writing will continue to happen in conventional word processors for the foreseeable future, because that’s where the existing infrastructure of publishing, business, and academia lives. Track changes, comments, and .docx compatibility aren’t optional for most working writers — they’re requirements imposed by the institutions those writers serve.

But at the margins, something is shifting. A growing minority of writers are deciding that the tools built for programmers solve their problems better than the tools built for them. They’re accepting the learning curve because the payoff — permanence, precision, independence — is worth it. And as the tooling around Markdown and Git continues to mature, with friendlier interfaces and better integrations, the barrier to entry keeps dropping.

The It’s FOSS guide frames this as a practical decision, not an ideological one. Learn a few Git commands. Write in Markdown. Commit often. Use branches for experiments. Push to a remote repository for backup. It’s a workflow, not a manifesto. But underneath the practical advice sits a philosophical claim that’s harder to dismiss: your words belong to you, and the format you store them in should reflect that.

For writers willing to invest a weekend in learning the basics, the tradeoff increasingly looks favorable. The files are tiny. The history is complete. The format will outlast every application on the market today. And the worst-case scenario — that you end up with a folder full of perfectly readable text files — isn’t really a worst case at all.