How to Use Git With WordPress: Workflows, Deployment, and Best Practices

Working with git with wordpress is more complicated than most developers expect the first time they try it. WordPress blends file-based code with database-driven content, and that combination creates friction that standard version control workflows were not designed to handle. The sections below break down what you need to know, from repository setup through deployment and database management.

Key Takeaways

WordPress mixes code and database content in ways that require a deliberate .gitignore strategy before your first commit.
Git-based deployment gives you commit history, rollback options, and team coordination that FTP cannot match.
Because Git cannot version a MySQL database, WordPress teams need WP-CLI, migration tools, and a clear environment plan.
Each layer of a WordPress Git setup builds on the last, and skipping one creates problems that surface at the worst time.
Common questions about Git and WordPress answered plainly.

Version Control for WordPress: What to Track and What to Ignore

Version control for WordPress works differently than version control for a standard software project. Most codebases let you track everything without consequence. A WordPress project does not give you that option. Commit the wrong things and your repository fills up with uploaded images, auto-generated cache files, and live database passwords.

The structural problem is this: WordPress keeps posts, comments, plugin settings, and site options in a MySQL database. Git tracks files on disk. Those two systems do not connect, and no configuration makes them overlap. Your job is to decide which files belong in Git and which do not.

What Goes in a WordPress .gitignore File?

A tight wordpress .gitignore file is what keeps your repository focused. The goal is simple: commit only the files your team writes, and exclude everything WordPress creates or downloads on its own.

Leave out the wp-content/uploads/ folder, the live wp-config.php file, WordPress core files if you manage them through Composer, compiled CSS or JavaScript from your build step, and any config files that change between environments.

Track your custom themes, custom plugins, a wp-config.php template with dummy values, your Composer files, and any deployment scripts the team uses.

The cleanest way to think about it: "code" is what your team writes. "Content" is what WordPress or your editors produce. Code goes in Git. Content does not.

This split protects you from two failures. The first is committing live credentials and exposing your database password in a repository. The second is storing binary image files in Git, which it handles poorly and which produce no useful history.

Start your .gitignore before your first commit. If you're adding Git to an existing site, audit the files on disk before you run git init. Cleaning up a repository that has tracked the wrong things for months takes far longer than getting it right at the start.

Deploy WordPress With Git: Hooks, CI/CD, and Branching Strategies

Deploying WordPress with Git changes the mechanics of how code reaches your server. With FTP or SFTP, a developer opens a client, drags files across, and has no record of what changed or when. There's no rollback. There's no coordination. If two developers push at the same time, one overwrites the other.

Git-based deployment fixes each of those problems. Every push is logged with a timestamp and an author. If something breaks, you check out an earlier commit. If two developers are working at once, they work in separate branches and merge through a review process.

Which Branching Strategy Fits Your WordPress Project?

The right wordpress branching strategy depends on team size and how often you ship. Small teams and solo developers usually do well with trunk-based development: most work happens on one main branch, with short-lived branches for individual features. Larger teams with formal release cycles tend to use Gitflow, which keeps features, releases, and hotfixes on separate branches.

The most practical starting point for most WordPress projects is environment-based branching. You keep three long-lived branches: development, staging, and production. Work starts in development, moves to staging for review and testing, and reaches production only after sign-off. At any moment, you can see exactly what code is running on each server.

Feature branches slot into this model. A developer branches off development, finishes the work, opens a pull request, and merges after review. Pull requests are where code review happens and where automated tests catch mistakes before they reach clients.

Git hooks wordpress deployment is the entry point for automation. A post-receive hook is a script your server runs every time it gets a push to a specific branch. It can pull the latest files, clear a cache, or restart a process. Hooks need server access and basic shell scripting, but they have no external dependencies and work with any Git host.

WordPress CI/CD pipelines go further. GitHub Actions, GitLab CI, and Bitbucket Pipelines each let you define steps that run on every push or pull request. A typical setup runs a linter, executes tests, deploys to staging automatically, and holds for approval before touching production. Tools like Deployer and Capistrano handle the file transfer and remote commands within those pipelines.

WordPress Database, Git, Tools, Security, and the Bedrock Approach

The wordpress database is the one part of a WordPress project that Git cannot touch. Git versions files. A MySQL database is not a file Git can read or track in any useful way. That's not a gap you can close with a plugin or a config option. It's a hard limit you need to work around.

WP-CLI is the most common tool teams use for this. It's a command-line interface for WordPress that lets you export and import the database, update options, manage plugins, and run search-and-replace on serialized data. In practice, a developer might export the production database before a deployment, store it somewhere safe, and import a copy of staging after the push goes through. That's not version control, but it gives you a known restore point.

Migration plugins do the same job with a graphical interface. Most handle the URL swap that WordPress needs when a site moves between domains, which makes them useful for pulling production data into a local or staging environment.

Local, staging, and production databases are never the same. Local has test content. Staging might have an anonymized copy of production data. Production holds the real data. Keeping those environments separate is what stops test content from reaching real users.

The wp-config.php file is where this gets risky. It holds your database host, name, username, and password. Commit it in its live form and those credentials sit in your Git history, visible to anyone with repository access. The fix is to commit a template file with placeholder values and build the real file from environment variables or a .env file at deploy time.

Bedrock wordpress git workflows solve this problem from the start. Bedrock is a project boilerplate from Roots.io. It uses Composer to manage WordPress core and plugins as versioned dependencies, stores all environment config in a .env file, and organizes the project so your .gitignore stays clean. Developers who use it get a repository that separates their code from WordPress internals without extra setup.

Even without Bedrock, Composer changes how you manage WordPress. When core and plugins are Composer dependencies, you stop tracking those files in Git. Your repository holds a composer.json and composer.lock that record exact versions. Any developer who clones the project runs composer install and gets the same files.

One more security note: audit your commit history for accidentally committed secrets. Rotating a leaked credential is not enough. The old value stays in your Git history until you rewrite it out, and anyone with repository access can read it.

The Bottom Line

A working WordPress Git setup is built in layers. You decide what to track. You pick a deployment method. You build a plan for the database. You keep credentials out of your commit history. None of those decisions is complicated on its own, but each one depends on the ones before it.

There's more to cover beyond these fundamentals, from local development tools that pair well with Git to advanced wordpress ci/cd pipelines that automate testing across every environment, including a wordpress staging environment that mirrors production.

FAQs

Do I need to version control WordPress core files?

Most teams skip WordPress core in Git. When you manage core as a Composer dependency, the composer.lock file records the exact version. Running composer install reproduces those files on any machine. That keeps your repository focused on the code your team actually writes and maintains.

What should I put in my WordPress .gitignore file?

Exclude wp-config.php, the wp-content/uploads/ directory, WordPress core files if you use Composer, compiled build assets, and environment-specific config files. Track custom themes, custom plugins, Composer files, and deployment scripts. A standard WordPress .gitignore template is a good starting point. Adjust it to match your project's structure.

How does WP-CLI help with git deployments?

WP-CLI handles the tasks Git cannot. You can use it to export and import databases, swap URLs between environments, toggle plugins, and flush caches. These commands run in shell scripts or CI/CD pipelines, making wp-cli git deployment steps repeatable across every environment without manual steps.

Can multiple developers work on the same WordPress site with Git?

Yes. Each developer works in a separate branch and opens a pull request before merging. Branch protection on production blocks direct pushes. Conflicts on shared files like functions.php show up as merge conflicts you can resolve, not silent overwrites you discover after the fact.

What is Bedrock and why do WordPress developers use it with Git?

Bedrock is a WordPress project boilerplate from Roots.io. It uses Composer for dependency management, stores environment config in a .env file, and structures the project so Git and deployment tools work cleanly from the start. Teams use it to avoid the credential and directory problems that come with a default WordPress install.