Managing local, dev and live versions of WordPress with Git

4 Views

I am looking at using git to manage version control for a WordPress project.

I typically have a local version, a development version on a web server that the client can access and test on and then a live version.

Read More

I will usually develop locally then push my changes to a repo on the server and then SSH into the dev folder on the server and pull from the repo. When I want to publish the changes on the live site I SSH into the live folder on the web server and pull from the repo.

Here is my dilemma.

I want the media added to the local version through the WordPress admin (image uploads etc) to be ignored but I want media added to the Dev version to be tracked so when I pull to the live site the media files from the dev site are pulled.

Any thoughts on the best way to make something like this work?

Post Views: 4

Related posts

Leave a Reply

1 comment

  1. There may be better solutions to this, but these two options have worked fine for me in similar situations. Let’s assume that the branch you work on locally is called master and in all your repositories the remote origin refers to the bare repository that you push to.

    1. If all your media fall neatly into one directory, you can have a separate repository that tracks the media and add that as a submodule to the dev and live repositories. In your local copy, you should either:

      • [in the situation where you want the live media locally] be careful not to (a) commit in your submodule, (b) push from it nor (c) add a new version of the submodule to your master branch
      • [in the situation where you don’t need those media at all in your local copy] not update and initialize the submodule at all – just add its path to .git/info/exclude

      Even if your media are in various directories you could still use this method, but managing submodules is a bit of a pain, and gets rapidly more irritating if you have lots of them.

    2. Alternatively, you can keep your dev and live repositories on a different branch, say called with-media, which is always the same as master but with commits that add the media at the end of the history. You can maintain this situation with git rebase. For example, if you’ve just made some changes locally that you want to push, you would do:

      git push origin master

ssh server
cd dev
# git branch should show you that you're on 'with-media'
git fetch origin
git rebase origin/master

      Now suppose you upload some files to the dev repository, and want to commit them:

      ssh server
cd dev
git add [whatever-media-files]
git commit
git push origin with-media

      Now to update your live repository, you can just do:

      ssh server
cd live
# git branch should show that you're on 'with-media'
git fetch origin
git merge origin/with-media

      To set up those branches in the first place, you would do:

      ssh server
cd dev
# git branch should show that you're on 'master', since you haven't created
# the other branch yet:
git checkout -b with-media
git push origin with-media

cd ~/live
git fetch origin
git checkout -t origin/with-media

      As one last note, suppose you make some changes in the dev repository that aren’t just adding media, and you want those code changes in your master branch. Then (before you push anything!) you need to reorder the history with git rebase -i origin/master.

        ssh server
  cd dev
  git rebase -i origin/master
  # Reorder the lines so that the non-media commits are first (earliest) in the file.
  # Save the file and exit your editor.

  # Now find the SHA1 sum (object name) of the last commit that has non-media changes.
  # (The object name of the commits will have been changed by the rebase.)
  git log --oneline

  # Let's say that was commit f414f3l.  Then you can push just the history up to and
  # including that commit back to the master branch with:
  git push origin f414f3l:master

  # Also push your 'with-media' branch back:
  git push origin with-media

      In an ideal world you won’t need to do those last steps often, but in practice it’s good to know how to do that 🙂