Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

WordPress and Git


Published on

A talk I gave at WordCamp UK 2013 in Lancaster, about using Git with WordPress: how to structure your project, what to ignore, etc.

Published in: Technology
  • Login to see the comments

  • Be the first to like this

WordPress and Git

  1. 1. WordPress and Git Rob Miller • @robmil
  2. 2. • I’ve been using WordPress since 0.72 • These days I’m Head of Digital at 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
  3. 3. Background
  4. 4. • 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?
  5. 5. A crash course in Git
  6. 6. 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
  7. 7. 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)
  8. 8. 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
  9. 9. Getting into Git • Sign up for GitHub • Read • git init and start playing!
  10. 10. Setting up a WordPress project
  11. 11. • What to ignore • Dealing with uploads • What to do with core files
  12. 12. What to ignore?
  13. 13. Configuration files
  14. 14. • 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?
  15. 15. • 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
  16. 16. 1. if ( file_exists( ‘local-config.php’ ) { 2. require_once ‘local-config.php’; 3. } else { 4. // Live settings 5. define(‘DB_HOST’, ‘localhost’); 6. define(‘DB_USER’, ‘example’); 7. define(‘DB_PASSWORD’, ‘example’); 8. define(‘DB_NAME’, ‘wordpress’); 9. } File-based switching
  17. 17. 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
  18. 18. • 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! Check for a file, then fall back to host-based switching
  19. 19. Uploads
  20. 20. • 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?
  21. 21. • 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
  22. 22. • 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
  23. 23. WordPress core files
  24. 24. • 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
  25. 25. • You end up with:
  26. 26. • 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
  27. 27. • 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
  28. 28. Core and Plugins
  29. 29. • Dealing with the plugins repository • Dealing with the core SVN repository • Generally: bypassing SVN
  30. 30. • 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
  31. 31. • git-svn is a built-in Git tool • Allows you to interact with (so checkout, update, commit, etc.) SVN repositories directly in Git
  32. 32. 1. # Create the repository from the remote: 2. git-svn clone -s 3. # Make some Git commits of your work 4. git commit -m “Something interesting” 5. # Get any new commits from SVN: 6. git-svn rebase 7. # Create an SVN commit for each Git commit: 8. git-svn dcommit A git-svn workflow
  33. 33. • 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?
  34. 34. • 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
  35. 35. • What about when you don’t have commit access, though? (e.g. core) • You can still generate patches from Git
  36. 36. • 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