Version Control (Git)

Git is a distributed version control system that tracks changes to files over time. Every change is recorded as a commit with an author, timestamp, and message. You can view the full history of any file, revert to a previous state, branch for experimental changes, and merge work from multiple collaborators. It’s the standard version control tool in software development, hosted on platforms like GitHub, GitLab, and Bitbucket.

For web development, Git is primarily used to track code: theme files, configuration, templates, and application logic. The database — where content and settings live on most CMS platforms — sits outside of Git by default, which means your content history isn’t tracked the same way your code history is.

Version Control and WordPress

In a typical WordPress setup, your wp-content directory (themes, plugins, uploads) goes into Git, but the content itself lives in MySQL. You can snapshot the database with tools like WP Migrate Pro or mysqldump, but it’s not the same as tracked history. Deploying WordPress across environments (local, staging, production) often involves manual database exports and imports, and keeping those environments in sync is a persistent friction point.

Some teams use plugins or workflows to manage this, but it’s a structural limitation of the architecture rather than a tooling problem.

Git and Statamic

Statamic’s flat-file CMS architecture changes this dynamic. Because content is stored as Markdown and YAML files on disk, it can live in your Git repository alongside your templates and code. Every content change — a new entry, an updated page, a modified global — is a file change that Git can track.

Statamic even has a built-in Git integration that automatically commits content changes when editors publish through the Control Panel. With a deployment pipeline set up, a content publish can trigger a commit, push to your repo, and deploy to production automatically. This creates a content history that’s as complete and reviewable as your code history, and it means deployment becomes a pull-and-serve operation rather than a database sync.

For teams that already work in Git-centric workflows, this is a significant quality-of-life improvement. Staging-to-production content promotion becomes a merge rather than a database export. Rollback becomes a revert rather than restoring a backup.

The tradeoff is that sites with high-frequency content updates or large editorial teams may find file-based storage limiting. For those cases, Statamic’s database mode stores content in a relational database while keeping templates and code in Git. See What’s the difference between Statamic’s flat-file and database modes? for more.

Git is also relevant during the migration process itself. Running a WordPress-to-Statamic migration inside a Git repository gives you a clean record of every step, makes it easy to collaborate, and provides a safety net if something needs to be unwound. See WordPress to Statamic Migration for how we approach this.