Quick answer: Using Git with WordPress means keeping your custom theme and plugin code in a version-controlled repository so every change is tracked, reviewable and reversible. You typically do not commit WordPress core, uploads or plugin zip files from the directory. Instead you version the code you own, deploy from Git to staging, then to production. That workflow reduces “who overwrote the header” disasters and makes handoffs between freelancers cleaner.
Why WordPress sites need Git
Many WordPress sites still change live files over SFTP. That works until two people edit the same template, a plugin update collides with custom code, or a bad CSS change goes live on Friday night with no clean rollback.
Git solves the history problem. You can see who changed what, compare versions, create branches for experiments and tag releases. Hosting panels and CI tools can pull a known commit instead of copying random folders by hand.
Git does not replace backups or staging. It complements them. Pair version control with a real staging copy of the site before you deploy, and keep a real website backup strategy for databases and uploads.
What belongs in the repository
Commit:
- Custom themes (or a child theme) you maintain
- Custom plugins you wrote
- Project docs: README, deploy notes, environment examples without secrets
- Build config if you compile assets (package.json, webpack config, and similar)
Usually ignore:
- WordPress core files (update them through proper updates, not Git)
wp-content/uploads(media lives on the server or object storage; too large and binary-heavy for most repos)- Third-party plugins installed from wordpress.org, unless you vendor them on purpose and accept the maintenance cost
node_modules, vendor caches and generated bundles you can rebuildwp-config.phpwith real credentials (use environment-specific config or secrets management)
A .gitignore tailored to WordPress prevents accidental commits of cache folders and local config. If you use a WordPress child theme, put that child theme at the center of the repo so parent theme updates stay separate.
A simple branching model that works
You do not need a complex enterprise GitFlow on day one. Try:
main(ormaster) always matches what should be deployable- Short-lived feature branches for each change (
feature/header-cta,fix/checkout-typo) - Pull requests or merge reviews when more than one person touches code
- Tags for production releases (
v1.4.0)
For solo freelancers, even committing to main locally with clear messages is better than no Git. Add review steps when a second developer joins.
Local development habits
Work on a local or containerized copy of the site when you can. Tools like Local, Docker-based stacks or a remote development site keep experiments off production. Pull the latest Git changes before you start. Commit small, logical units: one bugfix or one feature per commit when practical.
Never store production database passwords in the repo. Use environment variables or host-provided config. Document required constants in a sample file.
WP-CLI helps with scripted setup and searches. Teams that already use WP-CLI often wire Git deploys next, because both reward automation over clicking in wp-admin.
Deploying from Git
Common patterns in 2020:
- SSH pull on the server: Log in,
git pullon a bare release path, run build steps, switch a symlink - Host Git deploy hooks: Some managed WordPress hosts pull from GitHub or Bitbucket on push
- CI pipelines: Tests or build steps run, then artifacts sync to the server
Whatever you choose, deploy to staging first. Test the theme change, forms and critical plugins. Only then promote the same commit to production. A written website deployment process stops “it worked on my laptop” arguments.
Database changes (new pages, ACF field groups, plugin settings) are not fully captured by Git. Plan content migration separately. Some teams export config via plugins designed for that; others keep a checklist of admin steps for each release.
Handling plugins and WordPress updates
Git does not remove the need to update WordPress carefully. Decide:
- Who applies core and plugin updates
- Whether updates happen on staging first
- How custom code is re-tested after updates
Auto-updates can be fine for trusted plugins on low-risk sites, but custom themes still need a regression pass. See WordPress plugin auto-updates for the tradeoffs. Keep custom code in Git so you can diff what broke after an update.
Collaboration and agency handoffs
When agencies change, a Git repo with history is one of the highest-value assets you can transfer. Include:
- Repo access (GitHub, GitLab, Bitbucket)
- Branch and deploy docs
- List of required plugins and PHP version
- Who owns DNS and hosting
Without Git, the next team reverse-engineers production. With Git, they read history and continue. That is part of a sane ownership handover.
Mistakes to avoid
- Committing
uploadsand bloating the repo until clones crawl - Editing production over SFTP while also using Git, then force-pushing over someone else’s work
- Putting API keys in committed files
- One giant commit every month with message “updates”
- No staging site, so every merge is a live experiment
Also avoid treating page-builder JSON as invisible. If major layout lives in the database, Git alone will not protect it. Combine Git for code with backups for content.
FAQ
Do I need Git for a five-page brochure site?
If only one person edits rarely, disciplined backups may be enough. The moment you have custom PHP/CSS or a second contributor, Git pays for itself.
Should the whole wp-content folder be in Git?
Usually no. Track custom themes/plugins. Ignore uploads and most third-party plugins unless you have a deliberate vendoring policy.
Is Git the same as a backup?
No. Git tracks code history. You still need database and media backups, plus a restore test.
Can non-developers use Git?
They can learn basics, but many content editors should stay in wp-admin. Developers use Git; editors publish content. Train people for their role.
What about Bedrock or other modern WordPress stacks?
Composer-based setups pair naturally with Git and are excellent when your team is comfortable with them. They are optional. Plain WordPress plus Git for the theme still helps thousands of sites.
Getting started this week
- Create a private repository
- Add your custom theme with a solid
.gitignore - Make an initial commit and push
- Clone on staging and confirm the site runs from that copy
- Stop editing production theme files by hand
From there, add pull requests and automated deploys as your comfort grows.
Sample .gitignore themes worth copying carefully
Most WordPress Git templates ignore wp-config.php, uploads, cache directories, .DS_Store and dependency folders. Adjust for your build pipeline. If you compile CSS from SCSS, decide whether compiled CSS is committed or built during deploy. Pick one approach and document it so new developers do not guess.
Keep secrets out of history. If a key was committed by mistake, rotating the key matters more than rewriting Git history in a panic. Treat leaked credentials as live incidents.
Code review on WordPress projects
Even a fifteen-minute review catches debug var_dump calls left in templates, hardcoded staging URLs and CSS that breaks a checkout step. Require that pull requests describe how to test the change in wp-admin. Screenshots help for visual work; request/response notes help for AJAX endpoints.
If clients edit theme files in Appearance editors, discourage that. Those edits bypass Git and vanish on the next deploy. Train clients to use Customizer, custom CSS plugins that store in the database, or a documented process you control.
If you want a WordPress workflow that includes staging, Git and safer releases, see our Turn visitors into customers development services.
