Why your CMS should live in Git

A traditional CMS stores content in a database and your code in a repository. That split looks harmless until you need the things Git gives you for free:

• History. Every change, with author and timestamp, forever. No plugin required.
• Review. A pull request is a better editorial workflow than most CMS approval systems — diffs, comments, required reviewers.
• Rollback. git revert beats restoring last night's database backup.
• Environments. Branches give you staging for content, not just code.

The usual objection

"Editors won't use Git." True — and they shouldn't have to. The mistake is concluding that content therefore belongs in a database. The repository is the right storage; the terminal is the wrong interface.

That's the gap PatchCMS fills. Editors work on the rendered page, in their browser, with none of Git's vocabulary. The pull request happens behind the scenes:

# .patchcms.yml is optional — configure everything from the dashboard
collections:
  - path: content/blog
    url: /blog/{slug}

Content is code's neighbor, not its tenant

When content lives next to the templates that render it, the two can't drift apart. A field rename is one commit that updates both. A broken article is bisectable. Your CI can lint front matter the same way it lints code.

Your content deserves the same guarantees as your code. Put it in the repo.