“Integrating WordPress with GitHub” usually gets explained as a generic git tutorial — create a repo, clone it, commit, push — with no mention of what’s actually specific to a WordPress project. The real question isn’t how to use git, it’s what belongs in the repo at all, since a WordPress install has a mix of your code, third-party code, generated files, and secrets that shouldn’t all be treated the same way.
What to Actually Put Under Version Control
Track: your custom theme and plugin code — the files you actually write and review. That’s the entire point of version control: a history of changes to code you’re responsible for.
Don’t track WordPress core. Core updates through WordPress itself or Composer, and diffing thousands of core files on every WordPress version bump adds noise without adding safety — it’s not code your team is editing.
Don’t track wp-content/uploads. Media files aren’t code, they grow a repo to an unmanageable size fast, and they belong in a real backup/CDN strategy instead — not git.
Don’t track wp-config.php as-is, since it holds database credentials and secret keys. Keep a wp-config-sample.php in the repo as a template, and load the real values from environment variables or a git-ignored wp-config-local.php on each environment instead.
A Real .gitignore for WordPress
wp-config.php
wp-content/uploads/
wp-content/cache/
wp-content/upgrade/
node_modules/
vendor/
.env
.DS_StoreWhether vendor/ belongs in .gitignore depends on your deploy process: if your deployment step runs composer install on the server or in CI, ignore it; if you deploy a static built artifact with no build step on the target, you may need to commit it. Pick one and be consistent — a repo that sometimes has vendor/ committed and sometimes doesn’t is how deploys silently break.
Managing Dependencies with Composer
Third-party plugins and libraries generally shouldn’t be committed wholesale either — that’s what Composer is for, tracking exact versions in composer.json instead of thousands of vendor files in git. The Composer for WordPress dependencies guide covers setting this up in detail; it’s the piece that makes the .gitignore rules above actually work in practice.
The Local Workflow
Once the repo is scoped correctly, the actual git workflow is standard: initialize the repo in your project directory, add your tracked files, and push to GitHub.
git init
git add .
git commit -m "Initial commit"
git remote add origin <repository-url>
git push -u origin mainFrom there, branches and pull requests work exactly like any other git project — nothing WordPress-specific changes about how you collaborate once the repo itself is scoped correctly.
From Repo to Live Site
Getting code onto GitHub and getting it onto your live server are two different problems, and this is where a lot of “WordPress GitHub integration” content stops short. Two real options: WP Pusher is a plugin that pulls a theme or plugin directly from a GitHub repo with no CI setup required, a reasonable choice for a solo developer or a small site. For anything with a real testing/staging step, a GitHub Actions pipeline that deploys on push is the more durable setup — the CI/CD pipeline for WordPress development guide covers building that out with GitHub Actions, SSH deployment, and automated PHPCS checks in full.
If you’re starting a new themed project from scratch rather than retrofitting an existing one, building a custom WordPress theme from scratch is worth reading alongside this, since repo structure is easiest to get right from day one.
