Git is not just for code

Git tracks any text file: Markdown, AsciiDoc, LaTeX, plain prose. Writers, documentation teams, and academics use Git for the same reasons developers do - history, branches, parallel drafts, and merge resolution. The terminology takes some unlearning, but the workflow benefits are real.

Translation glossary

• Repository = a folder under version control.
• Commit = a saved snapshot of your changes, with a note explaining what changed.
• Branch = a parallel draft you can experiment in.
• Merge = combining a branch back into the main draft.
• Pull request = "please review and accept these changes."

A simple workflow

git init my-book
cd my-book
# Create chapters in Markdown
echo "# Chapter 1" > chapter-1.md
git add chapter-1.md
git commit -m "Add chapter 1 outline"

# Make changes
# ...edit chapter-1.md...
git commit -am "Expand chapter 1 introduction"

Using a GUI

Writers often find the command line uncomfortable. GUIs that work well for prose:

• GitHub Desktop - simplest, free.
• Sublime Merge - polished, fast.
• Tower - paid, very approachable.
• VS Code - the source control panel handles 90% of cases.

Plain-text formats win

Git diffs work line by line. Word documents are binary - Git treats them as opaque blobs and cannot show what changed. Markdown, AsciiDoc, and reStructuredText diff cleanly. For complex layout, use Pandoc to convert at build time.

pandoc -o book.pdf chapter-*.md

One sentence per line

A common convention in technical writing: end every sentence with a newline. This produces minimal diffs - editing one sentence does not reflow ten others - and makes review comments precise.

Branches for drafts

git checkout -b draft-second-edition
# rework freely
git checkout main         # original is intact
git merge draft-second-edition

Collaborating with editors

An editor can fork the manuscript, edit on a branch, and open a pull request. The author sees a side-by-side diff, comments inline, requests changes, and merges when satisfied. The same model that powers Linux kernel development works for novels.

Backups for free

Push to a private GitHub or GitLab repo and you have an off-site backup with full history. Lose your laptop, clone, and continue.

Things to ignore

Add a .gitignore so build artefacts and editor files do not get committed:

# .gitignore
*.pdf
*.docx
.DS_Store
.vscode/
_build/

The learning curve

An hour with a tutorial covers add, commit, push, pull, and branch - everything most writers need. The remaining 90% of Git is for cases you may never encounter. Start small; let real needs pull you deeper.