Let's be friends

Version control options with WordPress

Last updated: September 5, 2024

There are so many ways to utilize WordPress. Many people just edit it right up on the server or through some other portal. Some people have a 3rd party tool that makes it seem local but syncs to live. There really area just so many different ways people do these things.

The way we do it (in DFTW) is fully local – as if it’s a web application. That will require some more explicit setup first.

What are your options?

There are always options… and pros and cons…

  1. Just commit everything!

    • Pros: Simplest, no decision-making required, all files (core, themes, plugins, uploads, etc.) are included.
    • Cons: Results in a bloated repo with unnecessary files like WordPress core, which can be updated separately.
    • Use Case: Rare, mostly for very small or isolated projects where it’s important to have everything in one place (like a static backup).

  2. Commit only wp-content (themes, plugins, and file uploads/images)

    • Pros: Excludes WordPress core files but captures all your custom work (themes, plugins), user-generated content (uploads), and settings.
    • Cons: Uploads might not be necessary to track, and database changes aren’t captured in Git.
    • Use Case: Suitable if you’re working with a team that needs the whole wp-content folder for development but don’t want to track the core.

  3. Commit only custom theme and plugins

    • Pros: Focuses on your custom code (themes and plugins), making the repo clean and easy to manage.
    • Cons: Uploads and third-party plugins aren’t tracked; might need external backup/migration tools for media and databases.
    • Use Case: Ideal for most custom WordPress development scenarios. It’s clean and focuses only on what you’ve built.

    Sometimes, we do this – if we want to keep an expensive or possibly going away plugin stored away safely with git history.

  4. Commit only the theme

    • Pros: Simplest for theme-only development. Keeps the repo lean, focusing only on custom work.
    • Cons: Plugins, uploads, and settings aren’t tracked, so deployment or migration requires extra steps.
    • Use Case: Perfect for projects where only the theme is custom, and the rest (plugins, uploads) are managed outside of Git.

    This is what we usually do.

Git ignore patterns for WordPress

HTML element

git ignore for WordPress themes

# Ignore everything by default
/*

# Allow the .gitignore and README files
!.gitignore
!README.md

# Allow wp-content, but ignore everything inside it by default
!/wp-content
/wp-content/*

# Whitelist folders that contain custom code or resources
!/wp-content/themes
/wp-content/themes/*
!/wp-content/themes/YOUR_THEME_NAME_HERE

# Optionally, include plugins if developing custom ones (uncomment the line below)
# !/wp-content/plugins
# /wp-content/plugins/*

# Ignore sensitive files and WordPress core
/wp-admin/
/wp-includes/
index.php
license.txt
readme.html
wp-*.php
wp-config.php

# Ignore user uploads and cache files
/wp-content/uploads/
/wp-content/cache/

# Ignore OS and editor-specific files
.DS_Store
Thumbs.db
*.swp

You’ve used a .gitignore file, right? So, hopefully, you can tell what this is doing. If not, let’s talk about it.

Is this confusing? Want some moral support?

If you’re not feeling 100% with Git and .gitignores and breaking up commits and Tower and all that stuff, well – you’d better get some help! 🙂

And even if you are like – totally amazing and confident, maybe you can get on a call and talk about it with someone else while you do it. 😉
Let's be friends