What is a git-based CMS?

Three components, end to end:

1. Your repo holds the content. Pages are markdown files with YAML / TOML frontmatter; assets live in a folder you decide. The CMS does not own this — your existing static site generator (Astro, Hugo, Eleventy, Jekyll, …) reads it directly.

2. A schema sits alongside the content. In Norcube's case it lives under .norcube/cms/ in the same repo: collections describe what fields a page has, blocks describe reusable building blocks (hero, cta, faq), inputs hold shared single-field snippets. The schema is YAML, committed like everything else.

3. A visual editor renders typed inputs from the schema, validates on every save, and commits edits as real git commits via the GitHub App. There is no database between the CMS and your build — the editor literally writes the same files your build reads.

The headline consequence: when you cancel the CMS, nothing moves. Your content was always in your repo. Your schema was always in your repo. Your history was always in git. The editor was just one of several possible ways to produce commits on that branch.

Headless CMSes (Sanity, Contentful, Strapi, Hygraph, …) own the content in their database and expose it through an API. Your build fetches via REST or GraphQL at deploy time or runtime. The split gives you a few real advantages: any front-end can consume the same content, structured queries are first-class, and the editor can do things database backends do well (full-text search, referential integrity, derived fields).

The trade you make: an API contract between two systems that have to stay in sync, a database in the critical path of every deploy, and a migration project the day you switch vendors. For sites where the front-end is already static and the content lives in one place, the headless tax is real and not always worth it.

Git-based CMSes (Norcube CMS, CloudCannon, Decap, Tina, Keystatic, …) skip the API and the database. The editor is a UI on top of file writes; the build is whatever you had before. You give up first-class query support and shared content across many front-ends. You get back a much simpler dependency graph and zero exit cost.

Pick git-based when:

• your front-end is already static (Astro, Hugo, Eleventy, …)
• you want non-technical authors editing without learning markdown
• you do not want a database in the critical path of every deploy
• vendor lock-in is a deal-breaker

Pick API-first when:

• many surfaces (web, mobile, signage) read the same content
• structured query / search is first-class to your product
• editorial team is large enough to justify the headless tax

Three differences from the rest of the git-based category:

• AI scaffolding from existing content. Most git-based CMSes require you to write the schema by hand. Norcube CMS runs a multi-turn AI agent over your existing markdown, infers blocks, extracts shared shapes, and commits a starter .norcube/cms/ in one bundled commit. Re-run to refine.

• $ref shared blocks, strictly enforced. Define button once, reference it via $ref: button everywhere. The validator rejects schemas that inline the same shape in two blocks — so shared shapes can never silently drift.

• Pay-as-you-go, no per-seat. The CMS is in private beta and free right now; when we ship paid tiers, the cost is on sites and storage, not on people invited.

Per-product head-to-heads: CloudCannon, Decap, Tina, and Keystatic.