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.
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.
- [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
Alternatively, you can keep your dev and live repositories on a different branch, say called
with-media
, which is always the same asmaster
but with commits that add the media at the end of the history. You can maintain this situation withgit 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 withgit 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 :)
精彩评论