WordPress and GitRob Miller • @robmil
• I’ve been using WordPress since 0.72
• These days I’m Head of Digitalat Big Fish, a branding/marketing/design/digital/etc. consultancy based in West London
• We use WordPress for all our sites
• We’ve been using Git with WordPress for just over two years now
Background
• I first gave a version of this talk at WP London in November
• Turns out: it’s hard to teach people Git in an hour
• So I’m going to focus on WordPress
• What are the things to watch out for if you’re using Git when developing WordPress sites/plugins?
A crashcourse in Git
Git? Huh?
• A version control system (VCS)
• Track changes to your files over time
• Revert to any point in the past
• Branch to work on different features simultaneously
• Great for teams — no need to manually integrate work
Git’s advantages
• Works offline — commit, branch, do anything, without an internet connection and without having to connect to another server
• Fast, fast, fast
• Branching is cheap (and amazing)
Distributed version control
• Git is distributed
• cf. centralised systems like CVS, SVN
• Everyone has a fully functioning repository, with a full history
• There’s not necessarily a central, authoritative repository — forks are first-class citizens
Getting into Git
• Sign up for GitHub
• Read http://gitref.org/
• git init and start playing!
Setting up a WordPress project
• What to ignore
• Dealing with uploads
• What to do with core files
What to ignore?
Configuration files
• Configurations are different between development, staging, and live
• How do you manage these changed configurations without having the changes show up as modifications?
• How do you store configurations (so that new team members have them) while allowing them to be changed if necessary?
• Simplest solution: add your config files to your .gitignore
• Store sample config files that people can duplicate as appropriate
• Works okay, but can be better
• Two better options: switch when a file exists, or switch based on hostname
1. if ( file_exists( ‘local-config.php’ ) {2. require_once ‘local-config.php’;3. } else {4. // Live settings5. define(‘DB_HOST’, ‘localhost’);6. define(‘DB_USER’, ‘example’);7. define(‘DB_PASSWORD’, ‘example’);8. define(‘DB_NAME’, ‘wordpress’);9. }
File-based switching
1. if (2. preg_match(3. ‘/^dev\./’,4. $_SERVER[‘HTTP_HOST’]5. )6. ) {7. require_once ‘wp-config-dev.php’;8. } else {9. require_once ‘wp-config-live.php’;10. }
Host-based switching
• Decide whether having a config file that isn’t tracked is a benefit
• Do individual devs on your team want to make config changes that don’t get checked in?
• You can always do both! Checkfor a file, then fall back to host-based switching
Uploads
• Are uploads code, or content?
• If they’re code, it makes sense for them to be in version control
• If they’re content, it makes sense for them not to be
• But isn’t the answer… both?
• No easy solution
• Option one: ignore them entirely
• Option two: ignore them and add them manually
• Option three: ignore them and try to add them automatically/periodically
• Ignoring them entirely is definitely the cleaner solution
• But it’s untenable for us — we want people to be able to clone a repo and have a working site, not one with broken images everywhere
• So we track them, and periodically add new uploads from live
• Is still ugly, though
WordPress core files
• Put WordPress in its own folder
• Define WP_CONTENT_DIR and WP_CONTENT_URL
• Bingo: you have a wp/ directory that you can happily erase/overwrite without affecting your custom files
• You end up with:
• To submodule or not to submodule, though?
• Submodules are, like SVN’s externals, a way to have a repository within a repository
• Seems tempting, right? Track a tag on the WordPress GitHub, and then updating WordPress is just a git checkout away
• Unless you’re very aware of the caveats: don’t do it to yourself!
• Synchronisation issues — it’s possible for different devs to have different WordPress versions, which is bad
• Conflict resolution is nonexistent
• It generally adds complexity and another point of failure in your process
Core and Plugins
• Dealing with the WordPress.org plugins repository
• Dealing with the core SVN repository
• Generally: bypassing SVN
• WordPress is, for better or for worse (ok, for worse) an SVN ecosystem
• But we can deal with that without having to lower ourselves to using SVN
• git-svn to the rescue
• git-svn is a built-in Git tool
• Allows you to interact with (so checkout, update, commit, etc.) SVN repositories directly in Git
1. # Create the repository from the remote:2. git-svn clone -s http://example.com/svn/3. # Make some Git commits of your work4. git commit -m “Something interesting”5. # Get any new commits from SVN:6. git-svn rebase7. # Create an SVN commit for each Git commit:8. git-svn dcommit
A git-svn workflow
• Although you’re using SVN, you don’t actually have to use SVN
• You get to use all the features of Git — use it offline, branch cheaply, etc.
• You’ve got a Git repository, so you can use GitHub to collaborate with others
• Nobody needs to know you’re using Git; externally, it just looks like SVN
What does this mean?
• Another option worth mentioning:
• Just using them both at the same time
• Ignore .svn in Git; ignore .git in SVN
• Commit to each one independently, as and when you please
• So maybe use Git for actual VCS and SVN only for releases; YMMV
• What about when you don’t have commit access, though? (e.g. core)
• You can still generate patches from Git
• git diff --no-prefix > ~/feature.diff
• Generates an SVN-compatible diff that can be applied, as normal, with patch -p0
• To make it the default:
• git config --global diff.noprefix true
Top Related