Moving a WordPress site to repository-based deployments

Repository-based deployments mean the content of your site lives in a Git repository and every release is built and pushed from a commit, rather than uploaded by hand. For WordPress it is common to version-control the parts that are under your control (theme, plugins, wp-content) and treat the core and the database separately.

Structure the repo

• Version the theme and plugins. Your custom theme usually lives in wp-content/themes/<name>, and your plugins in wp-content/plugins. Track these so every change has history and can be rolled back.
• Track wp-content/uploads trade-offs. Media files are large and change often. Some teams commit uploads; most commit only a placeholder and sync media with the live host or an object store during deploy.
• Ignore wp-config.php and core. The config file holds credentials, so keep it out of the repo (see .env portability). WordPress core itself is normally updated through the dashboard or a dedicated core deployment step rather than tracked in the repo.
• Use a .gitignore. Exclude wp-config.php, wp-content/cache, object-cache dump files, logs, and any local-only folder such as .svn or .git inside a bundled plugin.

Define deploy steps

1. Pull on the target. On the production or staging server, run a deploy command that fetches the latest commit, for example git pull in the web root, or use a deploy tool such as Deployer that checks out a clean tree.
2. Move the uploads back after a clean checkout. A brand-new clone does not contain media, so link or copy the live uploads folder into the fresh wp-content location, or configure an object-storage integration.
3. Push plugin and theme changes, then activate in the dashboard. After a release, log in and run any required wp plugin update or theme re-save in a staging environment first so you catch breakage before production.
4. Use a branch for the next release. Keep main as the deployable branch and develop on a feature branch. Merge to main only after tests pass on staging.
5. Tag your releases. A tag such as v1.4.2 gives you an exact checkpoint to roll back to, which pairs with a restore drill rather than a manual "undo".

Handle database

• Treat the database as state, not code. Your schema and settings change with releases, so keep an export of the DB or a migration script alongside the repo, but do not try to merge database changes the way you merge code.
• Refresh staging from production for testing. Before each release, refresh the staging database from production (following staging database refresh) so the deploy is exercised against realistic data.
• Run search-replace on the DB after a host move. If the domain changes, fix any serialised URLs in the database with a careful search-and-replace (the WordPress search-replace tooling is covered in search-replace).

Prevention

• Deploy to staging automatically first. A webhook that runs the same build on staging catches file-permission and path issues before production sees them.
• Keep secrets out of history. If a real password was ever committed, rotate it now; the file may still exist in .git/history even if you removed it from the current tree.
• Document the deploy command in the repo README. New team members (or a future you) should be able to move the site to a fresh host from the instructions alone.

When to involve a professional

Bring in a hosting or DevOps specialist if you need a fully automated pipeline (GitHub Actions or similar) with database migration and zero-downtime deploys, or if an existing site has a messy root where separating core, plugins and uploads is not straightforward.