开发者

Managing local, dev and live versions of WordPress with Git

开发者 https://www.devze.com 2023-02-15 11:36 出处:网络
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

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.

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?


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 :)

0

精彩评论

暂无评论...
验证码 换一张
取 消