I am configuring Git along with my WP development environment, and I was wondering what should be tracked and what should be ignored. If it makes sense to track plugins and for WP core. Create one repo for both theme & plugins?

Common sense would suggest that tracking WP as a whole, is overkill and unuseful, as I am not involved in core development and updates; of course, I want to track my theme/child-theme folder where my work is. Plugins?

So I wonder what is the suggested setup, how many repositories and what to track/ignore


How should I structure a WP website project using git and updating from WP dashboard?

What is the best way to setup wordpress development environment for freelancers with version control?

  • 3
    if you don't track it as a whole, how exactly to you revert it to the state it was on 12/12/15? This is a question that will get different answers in different points in time and IMO is better to ask in SO how people maintain in git 3rd party libraries, as this is totally not a wordpress specific issue Sep 8, 2016 at 11:18
  • Well the question could be relevant to WP generally speaking on what parts are essential to include and what are not. For instance, if my project must be compatible with all WP versions maybe I could ignore the core from tracking? BTW, do you personally include the whole WP folder?
    – Riccardo
    Sep 8, 2016 at 13:08
  • 1
    The question was old when I first encountered it in the late 90s while working on real time software for telecommunication equipment. In theory you just track everything that is related to the product excluding maybe auto generated. Tracking everything obviously include configuration in the DB ;). If your product is, or you prefer to treat it like a collection of sub modules, then tracking each module (theme, plugin) by itself is fine. Which is why this is a workflow question which can be answered differently for different types of projects and different wordflows Sep 8, 2016 at 13:23
  • The question in the end is why do you bother to track changes at all. If it is only because high rep people on WPSE say so, then you are likely to not do it fully right (just committing to git is not enough, branching, comment etc is also important). You should do it in order to find out when a breaking change was introduced and/or why the code was written that way. If you believe that core updates will never break your site, then no point in tracking core files, and same about plugins. Sep 8, 2016 at 13:31
  • Personally I just committed few hours ago just plugins and themes directories which just means that I am as lazy as everyone else, and I don't believe that for that specific project at this stage tracking core is important Sep 8, 2016 at 13:31

3 Answers 3


Basically ignore everything except your theme folder and custom plugins. sample .gitignore:


# don't ignore the theme you're using

This makes the most sense when used together with composer for installing wordpress and plugins.

  • 6
    if all you want is your theme, then why do you set git at the root of wordpress install at all? Sep 8, 2016 at 13:10
  • 3
    because the wordpress root is probably the place where most people keep their composer.json.
    – skndstry
    Sep 10, 2016 at 4:21
  • 3
    I don't understand the purpose of this approach. Why use version control with Wordpress if you can't even use it to rollback a faulty Wordpress Core or plugin update? Apr 2, 2021 at 21:34

This is subjective and depends on what you are trying to achieve. A theme developer may have a different requirement than a plugin developer. Here is a good gist of a bare minimum .gitignore file for a WordPress install.

# -----------------------------------------------------------------
# .gitignore for WordPress @salcode
# ver 20160309
# From the root of your project run
# curl -Ohttps://gist.githubusercontent.com/salcode/b515f520d3f8207ecd04/raw/.gitignore
# to download this file
# By default all files are ignored.  You'll need to whitelist
# any mu-plugins, plugins, or themes you want to include in the repo.
# ignore everything in the root except the "wp-content" directory.

# ignore everything in the "wp-content" directory, except:
# mu-plugins, plugins, and themes directories

# ignore all mu-plugins, plugins, and themes
# unless explicitly whitelisted at the end of this file

# ignore all files starting with . or ~

# ignore node dependency directories (used by grunt)

# ignore OS generated files

# ignore Editor files

# ignore log files and databases

# ignore compiled files

# ignore packaged files

# -------------------------
# BEGIN Whitelisted Files
# -------------------------

# track these files, if they exist

# track these mu-plugins, plugins, and themes
# add your own entries here

It depends on the situation. However, in my view, Git versioning a WordPress site is often more hassle than it's worth. The reason is because tracking the state of the site can not be distilled down to merely the code that sits on your server; it also depends on the contents of the database. Unless you have a scheme to include some kind of database export in with your version control, it's not really a true way of tracking the site's state.

For most of my WordPress installs, I might have one custom developed theme/child theme and one custom developed plugin. These each get version controlled in their own Git repo. I make git commits from my local development environment and push changes to production via SSH, SFTP, or whatever makes sense for this specific server.

For production environment, I setup automated off-site backups of the /wp-content folder and the MySQL database.

This might not be exactly the answer you were looking for. However, in my experience, this has worked best for me in managing countless WordPress sites. I would love it if WordPress sites supported composer packages in a more native way, but ultimately, it's a different kind of animal.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.