I commit all WordPress because I consider it one big ball of code that pertains to one site, this means updates to core WordPress files, plugins and themes are all part of the commit history.
I don’t use sub-modules or any other weird nested revision setups. If you have a complicated structure of including multiple repos, I suggest keeping them separate and just using composer or another tool to update your main repo with files and not separate application histories.
What I do git ignore which is WP specific:
- Any cache or temp files ( for example
objectcache/,pgcache/, etc ) /wp-content/uploads/- Backup directories, logs, sitemaps
- Configs (
wp-config.php,.htaccess, any cache configs, etc)
Not every site is the same, I sometimes commit wp-config.php with multi-environment code, or sometimes I will commit /wp-content/uploads/ because it makes sense.
Also some plugins and themes upload media files into other locations which is annoying, so sometimes I blanket ignore file types.
Some opinionated notes:
I don’t understand why people don’t commit all WP in the repo, you have way less liability when you have WP changes in your history for updates (careful with auto-updates).
Take the time to get the setup right and test things, stuff will run a lot smoother having a good workflow as opposed to what happens if you try to change it later on.
I take the stance of committing more is better, because it sucks to turn around looking for something only to realize it’s not there. But is also sucks to commit things you don’t want so keeping it simple reduces brain meets desk scenarios.
Here is an example of a .gitignore I start with: https://gist.github.com/wycks/574052a64eee9307b06c