Git-Backed Content Management

What storing content in Git rather than a database really means — and why it matters for agencies.

Git commit history — content changes

In AstroForge, all content is stored in JSON files and versioned on GitHub. This is a fundamental departure from the database approach most CMS systems take.

Database vs Git: What's Different?

Database-backed CMS systems store content as momentary data. What was there yesterday, what the headline said two weeks ago — finding answers to those questions is hard. A wrong delete is often irreversible.

In Git, every change is a commit. History is preserved forever. A wrong change: reversed with git revert in a single command. Who changed what and when: visible in seconds with git blame.

In Practice with AstroForge

Every save made through the CMS is committed directly to GitHub by the astrocms Worker. The commit message identifies which page section was changed. This means:

  • Client changes are traceable
  • Bad content can be reverted if it goes live
  • If two people edit the same content, conflicts surface and can be resolved

Seed for Default Content

The npm run seed command generates JSON skeletons for all pages. Existing content is preserved; only missing keys are added. When a new organism is added, all page JSONs can have new keys merged in safely.

Limitations

Git-backed content has one drawback: extremely high-frequency updates (dozens of commits per minute) can hit GitHub API rate limits. For this scenario, batching CMS writes or using a temporary KV cache layer between the CMS and GitHub is a workable solution.