A git-based CMS stores content as markdown, MDX, or YAML files directly in your Git repository. When a writer saves a post, that action creates a Git commit, not a database record. The CMS is a UI layer that sits on top of your existing repository structure. Your content and your code live in the same place, under the same version control system.
This is a meaningful departure from how most content management systems work. Understanding the difference helps you pick the right tool.
Two kinds of headless CMS
The headless CMS market splits into two camps based on where content lives.
API-based CMS (Contentful, Sanity, Strapi): Content lives in a separate database managed by a third-party service. At build time or request time, your application fetches content through an HTTP API. The CMS vendor controls availability, pricing, and access to your data. If you cancel your subscription or the service goes offline, your content is not in your repository.
Git-based CMS (md0, Keystatic, Tina, Decap): Content lives in your repository as files. The CMS provides a visual editing interface that reads and writes those files through the GitHub API. There is no separate content store. Your content is yours, in plain text, committed to git alongside your code.
The practical difference: with an API-based CMS, your content is a dependency. With a git-based CMS, your content is just files.
How a git-based CMS works
The flow from edit to publish follows these steps:
- A writer opens the CMS dashboard and locates the file they want to change
- They edit content through a visual markdown editor (no raw markdown required)
- The CMS commits the change to the GitHub repository on their behalf
- The CI/CD pipeline detects the new commit and triggers a build
- The site rebuilds and the new content goes live
From the writer's perspective, this looks like saving a document. Under the hood, it is a standard git commit with an author, a timestamp, and a diff.
What this means for developers
Git-based content has concrete benefits for anyone maintaining a codebase:
Version control that works on content, not just code. git blame, git log, and git revert all operate on content files the same way they operate on source files. You can see who changed a headline and when, revert a bad edit, or audit the full history of a page.
No content API to maintain or pay for. There is no separate service to provision, no API keys to rotate, and no usage limits to worry about. Content retrieval is a local file read at build time.
Local development without internet access. Because files live in the repository, local development works on a laptop without network access. You do not need to connect to an external CMS to see real content.
Content reviews use pull requests. Teams can propose content changes through PRs the same way they propose code changes. Reviewers can comment, request changes, and approve. This pattern works well for regulated industries or teams with strict editorial processes.
No vendor lock-in. Your content is plain text files committed to git. Switching to a different CMS or dropping the CMS entirely leaves your content completely intact.
What this means for editors
Writers and content editors benefit from git-based systems too, even without touching the command line:
Changes are auditable. Every edit records who made it and when. There is no "who deleted this?" mystery.
Rollback is available. Reverting a bad change means reverting a git commit. No data is lost, and the process does not require engineering help if the team has set up a straightforward rollback workflow.
No markdown knowledge required if the CMS provides a visual editor. Most modern git-based CMSes include rich text editing that outputs markdown without exposing raw syntax to writers.
Access control mirrors GitHub permissions. If a writer has read-only access to a repository, they cannot publish directly to the main branch. Teams that already manage GitHub permissions get content access control for free.
When API-based CMS makes more sense
Git-based CMS is not the right tool for every situation.
Large non-technical editorial teams who cannot work within a GitHub-connected workflow will find git-based systems frustrating, even with a polished CMS UI. If dozens of editors work simultaneously across many content types, the PR-based review model may slow them down rather than help.
Complex relational content such as ecommerce catalogs, product relationships, or deeply structured data fits better in a purpose-built database with a dedicated query layer. Markdown files are not the right format for 10,000 SKUs with inventory metadata.
Extremely high content volume (thousands of records updated daily) is a poor fit. Generating a Git commit per save at that scale creates a messy commit history and can hit GitHub API rate limits.
Real-time personalization and A/B testing at the CMS layer typically requires an API-based system that can serve different content variants to different users without rebuilding the site.
Popular git-based CMS tools
| Tool | Status | Setup | Free tier | |---|---|---|---| | md0 CMS | Active | ~2 minutes, no config file | Yes (public repos) | | Keystatic | Active | 15-30 min, TypeScript config | Yes (open source) | | Tina CMS | Active | 30-60 min, GraphQL layer | Yes (self-hosted) | | Decap CMS | Minimal maintenance | 20-40 min, YAML config | Yes (open source) | | Forestry | Shut down April 22, 2023 | N/A | N/A |
A note on Decap CMS (formerly Netlify CMS): the project has sparse commit activity and a large backlog of open issues as of 2025. Teams should not start new projects on it.
Getting started
If you want to try a git-based CMS with your existing repository, md0 CMS connects to GitHub and reads your content structure without a configuration file. Setup takes about two minutes: authenticate with GitHub, select a repository, and your markdown files become editable through a visual editor.
For teams that want explicit TypeScript schemas, Keystatic is a strong alternative. For complex React-based sites with visual page building needs, Tina CMS is worth evaluating despite the longer setup time.