When I set up a GitHub repository for this project, I wasn’t thinking about version control in any disciplined way. I was thinking about having somewhere to keep things. Plans, designs, notes, and eventually — because it seemed sensible at some point along the way — the WordPress files themselves.
By the time I came to properly assess the situation, the repository contained the following things that had no business being there:
- Two SiteGround plugins (security and caching tools specific to that host)
- Three parent themes (Twenty Twenty-Three, Twenty Twenty-Four, Twenty Twenty-Five)
- A full WordPress cache directory
- A full set of language files
- A few stray WordPress config files
These aren’t my work. They’re either part of WordPress core, installed by the host, or generated automatically. Committing them to version control means tracking changes to things I didn’t write and don’t control — which is pointless — and it means the repository becomes enormous and slow for no reason.
What should stay
Version control exists to track your changes. For a WordPress project, that means:
- The child theme — the only files that are genuinely yours
- The database export — the content and settings that make it this site
- The uploads folder — media files referenced by the content
- Any project assets (documents, designs, notes) that belong to the project
Everything else either ships with WordPress, gets installed from a plugin directory, or gets generated at runtime. None of it belongs in git.
The .gitignore
One option to address this is a .gitignore file that tells git to stop tracking the things it shouldn’t be tracking.
I placed this inside the project-assets/Wordpress/ subdirectory rather than at the root of the repository, because the WordPress files all live there and the root already had its own .gitignore for other things.
The key entries:
wp-content/cache/
wp-content/languages/
wp-content/plugins/
wp-content/themes/twentytwentyfive/
wp-content/themes/twentytwentyfour/
wp-content/themes/twentytwentythree/
Deleting vs untracking
There’s a distinction worth making here. You can tell git to stop tracking a file while leaving it on disk, or you can delete it entirely.
On reflection, for things like parent themes and plugins, deleting made more sense — they’re not needed in the repository, and they’ll be present in any WordPress installation the project gets deployed to, so there’s no value in keeping a local copy.
git rm -r handles both in one step: removes the files from disk and removes them from the repository’s tracking in the same commit.
git rm -r wp-content/cache/
git rm -r wp-content/languages/
git rm -r wp-content/plugins/
git rm -r wp-content/themes/twentytwentyfive/
git rm -r wp-content/themes/twentytwentyfour/
git rm -r wp-content/themes/twentytwentythree/Much cleaner. That’s better.
The result
A single commit removed 1,255 files and 139,882 lines from the repository. It went from a bloated copy of part of a WordPress installation to a lean collection of the things that are actually specific to this project.
That’s what a WordPress repository should look like.
Part of a series — back to the overview
Leave a Reply