WordPress and Git Workflow

4 Views

I know this question has been asked a thousand times, but I’m really trying to work out how to get the best out of Git when working with WordPress.

I’ve scoured the web and read dozens of articles, all that seem to cover the topic briefly. Here’s a few of the most notable one’s I’ve read recently.

Read More

– Version Controlling WordPress

– Managing WordPress Theme Deployments with Git

– Manage your custom WordPress theme using git instead of FTP

Currently, my workflow looks like this.

  • Install WordPress locally
  • Develop Theme
  • Export WordPress Databases from local server
  • Import WordPress Database to remote server
  • Upload WordPress files and theme via FTP
  • Client makes changes
  • Download WordPress files and theme via FTP and export WordPress Databases from remote server
  • Replace files locally
  • Make development changes
  • Re-upload via FTP, export and import database to remote server

I realise Git can streamline this process. It seems the best way to do this is to have a .gitignore file that ignores certain directories that don’t need to be tracked, as well as having both a local and remote wp-config.php file.

But how do you handle the databases? Clients will usually make changes (posts/pages/plugins). Do I still need to export from the remote database and import back on my local server?

Can someone suggest the best workflow for me here? And walk me through the steps.

Also, I’d probably like to use Bitbucket as private repos with them are free, unlike GitHub.

Any help would be appreciated.

Thanks in advance!

Post Views: 4

Related posts

Leave a Reply

6 comments

  1. I’m one of the developers of WP Migrate DB Pro, and would like to answer @Ennui’s question:

    “Do you know if the db url replace script it runs takes into account serialized strings?”

    Yes, it does handle serialized data. In fact, that is the primary reason I developed the free version of the plugin back in 2009. 🙂

    Unfortunately I only have a reputation of 41, so couldn’t reply to @Ennui’s comment. Sorry for that.

  2. I am borderline on voting to close this as “not constructive” as it seems to be the kind of thing that will solicit debate and opinion rather than answers. But…

    That is not what my work flow looks like, and it makes my approach (and answer) different from most of the rest of the answers so far.

    1. Install WordPress locally
      1. This is cloned from a local bare Git repo containing the latest
        stable release.
      2. I also keep a local copy of the latest release of a few plugins that
        I nearly always install.
    2. Build the theme and any plugins necessary
    3. Upload to a public staging server
      1. The client is given access but can’t change the code and it told
        that database edits will not be transferred to the production site.
      2. This means that there is no reason to download the code back to the
        development server.
      3. And no reason to resync the local database
    4. Make changes to the local site based on our staff and the client’s feedback.
    5. Upload changes
    6. Repeat as necessary (but with increasing resistance 🙂 )
    7. If we are providing content, which is not always the case, we (not
      the client) will clean the database on the staging server and upload
      content.
    8. Deploy by uploading the local code to the production site.
    9. If we have created content, the content is exported from the staging
      site via the vanilla export tool and imported into the production
      site.

      1. This is the only time I have to move the database, and it is done
        with pretty standard tools. I will use Velvet Blues Update URLs to clean up the database if needed.
    10. Debug
    11. The end

    Basically, I keep the client away from my stuff as much as possible until we hand over the site.

    Code moves one way– from local to either staging or production. It never moves the other way. That eliminates some of your steps and give me some peace of mind. I do not want to be blamed for the client’s tinkering in my code and I don’t want to import some hacked file, which is a non-zero possibility.

    And the database only moves once, if at all, which greatly reduces the problem. So I guess I manage the “database moving” problem by reducing or removing the need to move the database. It also reduces database corruption issues that can arise and reduces the chances of importing a hack.

    True, I do have to configure the production site– permalinks, menus, etc.– but that forces me to work on the production site so I consider it a kind of debugging. It helps me confirm that things work on the production site the way they should.

  4. Take a look at the bedrock stack. It uses composer to manage the version of WordPress and third party plugins, and also includes capistrano for deploys, and vagrant / ansible for setting up servers including local virtual servers for development.

  5. I recently did a lot of testing regarding this and here is the workflow I use, which does pretty much what you’re asking for:

    • I use wp-cli to manage the wordpress core and update wordpress.
    • I use composer along with http://wpackagist.org to manage plugin and theme dependencies.
    • I use git and put core wp files in the .gitignore. So mostly wp-config.php and child theme files are in git.

    I’m not familiar with the db migration tools but would be a great addition to this workflow.

    Here are the full details on the workflow http://geekpad.ca/blog/post/maintainble-portable-wordpress-using-composer-wp-cli