A WordPress site is more than the files visible in its theme editor. It combines application code, database content, uploaded media, environment configuration, and the services that run the site. Git is valuable for tracking deliberate changes to code. A useful CMS workflow makes the remaining pieces equally explicit instead of assuming that a repository contains the whole website.

The practical objective is simple: a developer should know what to commit, an editor should know where to publish, and an operator should know how to release or restore the site. Start with those responsibilities. The CMS and framework guides cover the broader architecture; this workflow applies it to everyday WordPress development.

Separate code from changing site content

Track the custom theme, custom plugins, build configuration, deployment scripts, and documentation your team actively maintains. Treat published posts, comments, settings stored in the database, and visitor submissions as application data. Uploaded media also needs persistent storage and its own backup process.

The WordPress version control handbook describes how revision history helps track and restore code changes. That is the foundation for a developer workflow, but a code revision alone cannot describe every later content edit or customer action on a running site.

Write a short inventory with three columns: component, authoritative location, and recovery method. Include the database, upload directory or object store, custom code, installed dependencies, and environment configuration. This inventory becomes the reference when a deployment or backup discussion uses the ambiguous phrase “the whole site.”

Choose a repository boundary you can explain

A theme-only repository suits a team responsible for one theme. A project repository can hold multiple custom components and the tooling that assembles the installation. Either can work if a fresh checkout has clear instructions for reconstructing the expected environment.

Avoid editing WordPress core as a routine customization strategy. Put project behavior in the appropriate theme, child theme, or plugin, and document any exceptional patch that must be maintained. Otherwise an update and a deployment may each believe they own the same files.

Decide how third-party dependencies are obtained. If a package workflow manages them, record the dependency definitions and the versions needed to reproduce the release. If the repository deliberately includes an external component, document its origin, update process, and distribution rights. Do not leave installation dependent on an undocumented folder copied from one developer's laptop.

Keep environment values out of commits

Production database credentials, authentication secrets, and service tokens belong in the environment's protected configuration. Commit a documented example containing placeholders so developers understand the required settings. Review configuration changes as carefully as code changes, including any new variable introduced by a plugin or deployment script.

A project rooted at a conventional WordPress installation might begin with exclusions like these, adjusted to its actual structure:

/wp-config.php
/.env
/wp-content/uploads/
/wp-content/cache/
/node_modules/
*.log

This is an example, not a complete policy. A repository containing only a theme needs different paths. An ignore rule also does not remove material already committed. Inspect the tracked files before relying on the rule, and rotate exposed credentials if a secret entered history. Deleting the visible file is not equivalent to invalidating its value.

Build a repeatable local development path

Document the required runtime, database setup, dependency installation, and command used to build frontend assets. Use a small development dataset wherever possible. When production data is necessary for diagnosis, follow the team's handling rules and remove information that developers do not need.

Make the initial setup testable by someone who did not write it. They should be able to create the environment, activate the relevant components, and reach a representative page without private instructions. Keep environment-specific domain names and local filesystem paths out of reusable source files.

For a styling change, describe the page states reviewers should inspect: navigation, long titles, empty results, mobile layouts, and logged-in behavior where relevant. For a plugin change, explain the affected action and expected outcome. A screenshot helps review presentation, while a reproducible action helps review behavior.

Use branches to package coherent changes

Create a focused branch for an identifiable change, such as a new content block or a search template fix. Keep unrelated formatting, dependency upgrades, and feature work separate when they would require different review decisions. Commit messages should explain the purpose of the change in terms a future maintainer can understand.

Before proposing a release, inspect the diff for generated noise, copied uploads, temporary exports, and accidental configuration values. Confirm whether compiled assets belong in the repository or are created by the build. Apply the same choice consistently so reviewers can distinguish source edits from outputs.

When AI tools assist development, inspect their changes with the same review process. Ask the author to explain unfamiliar hooks, escaping behavior, and dependency additions. The AI IDE Git workflow offers a practical pattern for keeping generated edits understandable and reversible.

Treat database changes as release work

Changing a plugin can also change the schema or meaning of stored data. Record whether a release requires a migration, a one-time setup action, or an editorial adjustment. Test those steps against a representative staging environment before the production release.

Do not copy a staging database over production merely to move a layout change. That operation can overwrite newer posts, users, orders, submissions, or settings. Identify the specific configuration or content change that must move, then choose a method appropriate to that data.

For every migration, consider what happens if application code is rolled back afterward. Can the previous release still read the changed data? If not, the recovery plan needs more than an older theme ZIP. Define the database recovery point and the effect of restoring it on content created since that point.

Account for templates edited in the dashboard

With block themes, a template customized through the Site Editor can be stored in the database and take precedence over a theme's template file. That means a developer can deploy a changed file and still see the customized version on the site. Investigate where the active template comes from before concluding that deployment failed.

Agree whether a particular design change is an editorial customization or a reusable theme change. If it belongs in the theme, move the intended template into the theme source using the appropriate workflow, review it, and test with the relevant customization state. Avoid clearing production customizations merely to make a deployment appear successful; they may contain deliberate work that has never entered Git.

Deploy without taking ownership of uploads

Build a release package that contains the code and assets the release actually owns. Keep persistent uploads outside any directory that is replaced as a unit, or configure deployment exclusions deliberately. A cleanup step should never discover its scope by treating every unfamiliar production file as disposable.

For shared hosting, document the upload destination, extraction procedure, permissions, and activation step. For a VPS, document the release directory and service behavior. In both cases, identify the deployed commit and verify a small set of representative pages and administrative actions after release.

Agree on how urgent production fixes enter the repository. An emergency edit that remains only on the server will disappear during a later deployment. Capture it promptly, review it, and reconcile the installed version with the tracked source before ordinary release work resumes.

Make updates and backups part of ownership

Decide who manages WordPress, theme, and plugin updates and how that process interacts with deployment. If the team limits dashboard file editing or installation, provide a dependable replacement workflow. A restriction without a maintained update process can leave essential maintenance waiting indefinitely.

Back up the database and required site files independently of the source repository. Retain the configuration information needed to reconnect the restored application to its services, while protecting secrets appropriately. The Git backup and recovery guide explains why restoring a repository and restoring a live service are separate checks.

Frequently asked questions

Should uploaded images go into the theme repository?

Theme-owned interface assets can belong with theme source. Editorial uploads usually belong with site content and persistent media storage. Classify the image by who changes it and how it should survive a deployment, rather than by its file extension alone.

Can Git undo a bad plugin update?

It can help restore tracked plugin code or the project configuration that selected that code. Whether that restores the working site depends on database changes, external services, and compatibility. Rehearse the rollback for the particular update instead of assuming code reversal is sufficient.

Does every CMS need the same repository layout?

No. The useful pattern is consistent ownership of source, configuration, content, and runtime state. Adapt the directory layout to the CMS and hosting environment, then document the build and recovery steps that connect them.

Leave the next maintainer a clear route

A clean CMS repository explains what it controls and how its code reaches production. Pair it with an explicit content backup process and a tested release checklist. That combination makes everyday changes easier to review and gives the team a practical route back when a deployment affects more than a few files.