Git Workflows for WordPress Agencies

Disclosure: This guide on Git Workflows for WordPress Agencies contains affiliate links to selected tools. Our independence ensures we only recommend platforms that genuine

If your team still edits functions.php through wp-admin’s plugin editor on a live client site, you already know the failure mode: a typo takes down the homepage at 4:58pm on a Friday, nobody has a record of what changed, and the only way back is a database backup from two days ago. Git-based deploys exist to make that scenario structurally impossible. This is the workflow agencies actually run once they’ve been burned once.

Why “just edit it live” stops working past client #3

One site, one developer, occasional tweaks — live editing is fine. The moment you’re running 10+ client sites with 2-3 developers touching them, you need three things live editing can’t give you: a record of who changed what and when, a way to test a change before it hits production, and a one-command rollback. Git provides all three; wp-admin provides none.

The stack that actually works

Most agencies converge on a version of the same pipeline: local development with version-controlled code, a Git host for the repo and pull requests, and an automated deploy step that pushes approved commits to staging and then production.

1. Local environment

Local by Flywheel (free) or DDEV (free, open source) for spinning up per-project WordPress instances on a laptop. DDEV has pulled ahead for teams that want Docker-based environments they can also run in CI, since the same .ddev config that runs on a developer’s machine can run in GitHub Actions.

2. Dependency management: Bedrock vs. classic WordPress

Roots’ Bedrock (free, open source) restructures WordPress so plugins, themes, and WordPress core itself are Composer dependencies pinned to exact versions in composer.lock, and only your theme/custom plugin code lives in the repo — not the whole wp-content folder. This is the single biggest lever for making Git workflows sane at agency scale: your repo stays small, diffs stay readable, and “what plugin version is on production” becomes a one-line lookup instead of a guessing game. The tradeoff is real: Bedrock has a learning curve, and a client’s existing site built on plain WordPress needs migration work to adopt it. Plenty of agencies stick with classic WordPress and just .gitignore the uploads folder and vendor plugins — it works, it’s just messier.

3. Git host and code review

GitHub is the default choice — free for public repos and private repos with unlimited collaborators, with Team plan pricing around $4/user/month for advanced branch protection and required reviews. GitLab’s free tier includes built-in CI/CD minutes, which some agencies prefer since it skips a separate CI tool. Bitbucket still has a following among agencies already on Atlassian (Jira, Confluence) for client project management. For a two-to-five-person dev team, the actual git-hosting cost is usually $0-20/month regardless of which you pick — the differentiator is CI minutes and review tooling, not price.

4. Auto-deploy on push

This is where the workflow becomes real instead of theoretical. Three common paths:

• Host-native git push — WP Engine, Kinsta, and Pantheon all support pushing directly to a remote the host provides, deploying on push to a chosen environment. No third-party tool, but you’re locked into that host’s git implementation.
• DeployHQ (from around $18/month) — host-agnostic deploy automation that works over SFTP/SSH to almost any WordPress host, including budget VPS setups. Good fit if your agency’s clients are spread across different hosts rather than consolidated on one.
• Buddy (free tier for up to 5 projects, Team plan around $75/month) — heavier CI/CD tool that can run build steps (compile SCSS, minify JS, run PHPCS) before deploying, not just copy files.

[AFFILIATE CTA: Kinsta]

5. The branch model that fits agency work

Skip elaborate Git-flow setups built for product teams — client site work doesn’t need them. A simple three-tier model covers almost every agency: a main branch that mirrors production, a staging branch that auto-deploys to a staging environment on every push, and short-lived feature branches per task that get a pull request review before merging to staging. Production deploys happen by merging staging into main, ideally with a manual approval step so nobody accidentally ships a half-tested client redesign at 5pm.

What still has to happen outside Git

Git tracks code, not the database or media uploads. You still need a separate plan for syncing content between environments — WP Migrate DB Pro (around $199/year for the agency-tier license, unlimited sites) is the standard tool for pushing/pulling the database and media between local, staging, and production without overwriting a client’s live orders or form submissions. Skipping this is the most common reason agencies who “do Git” still end up manually re-entering content after a deploy.

Honest tradeoffs

This setup is overkill for a five-page brochure site you’ll touch twice a year — the overhead of branches, PRs, and staging environments only pays off once you have recurring maintenance work or multiple developers touching the same codebase. It also adds a real cost: a staging environment per client site, which on most managed WP hosts means paying for an extra site slot. Budget for it in your retainer pricing rather than eating it.

The verdict

For any agency with 2+ developers or 10+ maintained sites: Bedrock (or at minimum a disciplined .gitignore) plus GitHub plus a host-native or DeployHQ auto-deploy, with WP Migrate DB Pro handling the database side. That combination costs under $50/month in tooling for most agency sizes and eliminates the “who changed what” and “how do we roll back” problems entirely. For a one-developer shop with a handful of low-maintenance sites, plain SFTP with disciplined manual backups before every change is still a defensible choice — just don’t scale it past client #5 without revisiting this.

FAQ

Do I need Bedrock to use Git with WordPress?
No. You can put a standard WordPress install under version control and .gitignore core files, uploads, and cache directories. Bedrock just makes the resulting repo cleaner and dependency versions explicit — it’s a quality-of-life upgrade, not a requirement.

What’s the cheapest way to start if we’re currently editing live?
GitHub free tier plus your host’s native git-push deploy (if WP Engine, Kinsta, or Pantheon) costs nothing beyond what you’re already paying for hosting. Add DeployHQ’s entry tier later if you outgrow host-native deploys or work across multiple hosts.

How do we handle a client who wants to make their own content edits?
Content (posts, pages, most media) stays in the database and is unaffected by your Git workflow — clients keep editing through wp-admin as normal. Git only governs code: theme files, custom plugins, and configuration. The two systems run in parallel without conflict.

Is GitHub Actions worth setting up for a small agency?
Even a minimal Actions workflow that runs PHPCS (WordPress coding standards linting) on every pull request catches a meaningful share of bugs before they reach staging, and the free tier’s 2,000 minutes/month covers most small agencies without ever hitting a paywall.

Related reading: Docker for WordPress Agency Setups · Local by Flywheel for Agency Development · Case Study