WordPress version control: Git handles the code, so what handles the rest?

Updated October 30, 2026

Git is the right answer for WordPress version control, for about half of your site.

Your theme, your custom plugin and your functions.php are files. Git is brilliant at files. But your pages, menus, widgets, settings, WooCommerce products and page builder layouts all live in the database, and Git can't see any of it.

That's the problem every developer hits on their second WordPress project.

What Git covers on a WordPress site

Most WordPress Git setups track wp-content, or just the theme and custom plugins inside it. Some track the whole install. Either way, you get the usual: commits, branches, diffs, blame and a clean way to deploy.

What you don't get is the database. WP Engine's development guide puts the standard rule plainly: code moves up to production, and the database moves down to development. It also says it's "never advised" to include a database when copying to a live site, because copying a dev database up "will destroy newly added, live data". New orders, new comments, the blog post the client published this morning: all gone.

So on a normal site, your Git history can tell you exactly when someone changed the header template. It can't tell you when someone deleted the "Pricing" item from the main menu.

What tried to fix the database side

VersionPress

VersionPress was the famous attempt to put the whole site, database included, into Git. Its GitHub repo was archived on July 28, 2024, and as of October 2026 its README still says it "is not actively developed" and "is not production-ready yet". Don't build a workflow on it.

Database dumps in Git

Some teams commit a SQL export now and then. It gives you a point to restore to, but it's a snapshot of everything at once. You can't undo one menu change from a dump without also undoing everything else that happened since.

Core revisions

WordPress keeps revisions of posts and pages, tracking the title, author, content and excerpt. That's a version history for your writing. Menus, widgets, settings and most plugin data have none. (Details in WordPress revisions.)

Backups

Backups are your disaster recovery and you should have them. But they're all-or-nothing: restoring last night's backup to fix one bad edit also throws away everything since.

How Kitepod versions the parts Git can't

The database half needs history at the level of a single change, and that's what Kitepod keeps for whatever your assistant changes. It wasn't built as a Git replacement. But every edit the assistant makes, to theme files or to the database, goes through Kitepod first and gets recorded.

Theme code: draft themes and 10 generations

When the assistant edits theme files, it never edits the live theme. It works in a draft theme, either a copy of the active theme or a new child theme. PHP is linted before it saves.

Publishing the draft (a step that waits for a person's approval by default) health-checks the home page and the REST API, and swaps the old theme back automatically if there's a fatal error. Kitepod keeps the last 10 theme generations for rollback, so "put the theme back to how it was two publishes ago" is a single request.

Content and settings: snapshots and change sets

Every write is snapshotted before it happens: posts, pages, menus, widgets, settings, design changes, builder layouts and files in wp-content (each file's previous bytes are captured first). Plugin, theme and core updates get a checkpoint each.

Undo works per edit, per task (a change set) or per session, for 90 days. It's the closest thing to git revert for the database that most sites will ever have.

There's also an audit trail of who asked for each change, what changed and who approved it, hash-chained on the site and in Kitepod.

Where Kitepod's history stops

Kitepod's snapshots cover changes made through Kitepod. Someone editing a page by hand in wp-admin isn't captured (core revisions still apply to their post edits). Snapshots are normally deleted after 90 days, so they aren't an archive. And Kitepod isn't a backup service. Keep real backups.

It also doesn't write to your Git repo. Theme edits happen on the server, in the draft theme. If your theme lives in Git, pull the changed files back into the repo before your next deploy, or the deploy will overwrite them. Developers working this way usually do it from Cursor or Codex, where the repo is open anyway.

The setup we'd suggest

1. Git for your custom theme and plugins, deployed the normal way.
2. A real backup on a schedule, from your host or a backup plugin.
3. Kitepod for everything your assistant changes, with snapshots, change sets and the 10-generation theme history.

If you haven't connected an assistant yet, the WordPress MCP page explains the options.

Finer points

Can I put my whole WordPress site in Git?

You can commit all the files, including core. You can't usefully version the live database in Git, which is where content and settings live. Most teams track wp-content or just their custom code.

Should the uploads folder go in Git?

Usually not. It's large, it changes every time someone adds an image, and it's tied to rows in the database anyway. Back it up instead.

Is VersionPress still an option?

Not for production. Its repository was archived in July 2024 and the project says it isn't actively developed.

Does Kitepod replace Git?

No. Git is better for code you write yourself, with branches, reviews and deploys. Kitepod covers the live site's database and the changes your assistant makes, which Git can't see.

How far back can I undo with Kitepod?

90 days for snapshots of content and settings. For theme code, the last 10 generations of the draft-theme publish history.