|# .gitignore for WordPress @salcode|
|# ver 20180808|
|# From the root of your project run|
|# curl -O https://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.|
|# To ignore uncommitted changes in a file that is already tracked, use|
|# git update-index --assume-unchanged|
|# To stop tracking a file that is currently tracked, use|
|# git rm --cached|
|# Change Log:|
|# 20180808 unignore site.webmanifest|
|# 20180714 unignore .phpcs.xml.dist|
|# 20160309 Added favicon files as whitelisted files|
|# 20150302 Added composer.json as a whitelisted file|
|# 20150227 Created as fork of https://gist.github.com/salcode/9940509,|
|# this version ignores all files by default|
|# 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 favicon files, if they exist|
|# track these mu-plugins, plugins, and themes|
|# add your own entries here|
It may seem strange that I'm ignoring all files by default. I've started using Git for deploying my WordPress work. In the process, I've found it helpful not to have plugins included in the repo.
In the prior version I worked from, .gitignore file for WordPress - Bare Minimum Git, it was necessary to modify the
@mfi-dev, I've been using composer to manage public plugins, see http://salferrarello.com/composer-wordpress-plugins/. I have not worked out a solution for commercial plugins but others apparently have using https://github.com/composer/satis.
@camaech I generally I don't make that kind of drastic change to an existing repo. I use this
You could add this file to an existing project and then delete files from the repo but leave them on your local disk. See this Stackoverflow Remove file from the repository but keep it locally. However, be careful if you're using git to deploy your website because it will record the deletion of the files and delete them on your server when you deploy.
Short version Don't change existing repos. Use this on new repos. If you really want to use this on an old repo, use the files to create an entirely new repo (and sacrifice your history).
re: # ignore everything in the root except the "wp-content" directory.
Um. Then why not just make that directory the repo?
My understanding is, for the sake of consistency and completeness, etc. that you should in fact include WP Core. Why? Because that "snapshot" (of code) if you will is part of the history of the project. It becomes part of the status of the codebase at any given moment.
For example, if such and such (e.g., plugin, custom X, Y or Z, etc.) was added to the project under (say) WP 4.1.1 and that feature goes wonky in (again, just an example) 4.1.2 then you might need to know where WP Core was when that feature was added.
Maybe this is wrong? But when someone explained it to me (or did I read it?) it made much sense.
One certainly could set the root as
I understand the desire for a snapshot in time however I don't think the "cost" of including all of WordPress core is worth it for a couple of reasons.
All of my client sites update WordPress through the web interface, not by changing the files in the repo. This means I'm going to be out-of-sync anyway. I prefer to run the latest on both
I don't think there is one single answer on how to version control your website. Personally, I have found using this
I bet, the idea was to be able to run the site the way it was at some arbitrary commit. For example, you see the code, but can't figure out what it does. Sometimes it's better to debug the code, then try to do it in your head.
Unfortunately, these two doesn't explain anything. They assume whoever reads this post trusts you on your choice. Honestly, I don't. Not since I have reasons to not trust you. But since I have no reasons to trust you yet. So these ones doesn't count for me as they are.
In this case, I would add
Overall, it sounds like you want to check WordPress core into your Git repo. While I personally wouldn't do that for my reasons listed above, I have no problem if you choose to. Different people like different things. All the best.
@salcode Since you whitelist some folders (theme, plugins) at the end of the
(I had this problem with
@michelluarasi I'm not able to recreate the behavior you're describing.
For example if I:
I still don't see
Can you describe the steps to reproduce the behavior you're seeing? Thanks.