Version Control as a CMS Feature

Content management systems typically implement version history as a database feature. WordPress stores post revisions as additional rows. Ghost maintains a revision table. The version history is queryable, restorable through the admin interface, and entirely dependent on the database that contains it.

A flat-file publishing system backed by Git has a different version history model. Every commit is a snapshot of every file in the repository. The history is complete, cryptographically verified, and stored in a format designed for exactly this purpose. Rolling back a post to a previous version is a Git operation, not a CMS operation.

The practical implications are several. First, the history is portable. The Git repository contains the complete editorial record. Moving to a different publishing system does not orphan the revision history. Second, the history is auditable. Every change is attributed to a committer, timestamped, and associated with a commit message that can describe why the change was made. Third, the history is branched. Draft work can live on a feature branch, reviewed before merge, and published by merging to main — a workflow familiar from software development that maps cleanly onto editorial review.

The limitation is that Git history is a technical artifact. It requires Git tooling to navigate. A non-technical editor cannot browse revision history through a web interface without additional tooling. This is a real constraint for collaborative publishing operations where contributors are not comfortable with version control.

For a solo publisher or a small technically-literate team, it is not a constraint at all. It is a feature. The CMS revision system is replaced by a better version of itself, with no additional infrastructure required.