Writing like a developer: my Markdown + Git workflow for prose

For a long time I wrote everything in a word processor. Files were called article_final.docx, then article_final2.docx, and eventually article_REALLY_final.docx. Anyone who writes knows the feeling. Since I switched to plain text in Markdown, with Git underneath, that problem is gone. You don't have to be a developer to work this way. Here's how I do it.

1. One folder, one file per piece

Every project gets its own folder, and every piece its own .md file:

writing/
  2026-10-blog-writing-routine.md
  2026-10-newsletter.md
  ideas.md
  README.md

Putting the date first keeps everything in order automatically. ideas.md is a plain list of loose thoughts. README.md explains in three lines what the folder is for, so I still understand it six months from now.

2. Frontmatter for metadata

At the top of every file there's a small YAML block:

---
title: Why I write every morning
status: draft
tags: [writing, routine]
---

Plenty of blogging platforms and static site generators read this directly. And I can see at a glance which pieces are still in draft.

3. One sentence per line

This sounds odd, but it works really well. I put every sentence on its own line. Markdown joins lines within a paragraph anyway, so readers never notice. The benefit: when I rewrite one sentence, Git shows exactly that one line as changed instead of an entire paragraph.

4. Small commits with clear messages

git add 2026-10-blog-writing-routine.md
git commit -m "Shorten intro, add second example"

I commit after every real writing session. I write the message for myself three months from now: what changed and why. If I want to go back to an earlier version, it's right there in git log.

5. Look at changes word by word

A regular git diff compares whole lines. For prose, this is much more useful:

git diff --word-diff

It shows you, word by word, what was removed and what was added. It's like track changes in a word processor, without the document drowning in red strikethroughs.

6. Branches for experiments

Not sure about a different structure for a piece? I create a branch:

git switch -c new-structure

If it doesn't work, I switch back to main and nothing is lost. If it does, I merge it.

7. Export when someone wants Word

Not everyone works in Markdown. With Pandoc you can convert a file in a single line:

pandoc 2026-10-blog-writing-routine.md -o writing-routine.docx

My source always stays plain text, and the other person gets the format they're used to.

Why this works better

Plain text doesn't break, opens in any editor and will still be readable in twenty years. Git gives you a full history without you having to think about it. It takes an afternoon to get used to. After that, you won't want to go back.

How do you manage your writing? I'm curious whether anyone has automated this even further.