Git Workflow with WordPress - Localhost to Live

问题:

I have a basic but common WordPress workflow question.

Current Workflow

1. I develop everything locally
2. FTP files (and database dump) up to the server to show client
3. Make requested changes locally
4. FTP files (and database dump) up the server again
5. More local edits
6. FTP (and database dump) up again
7. Rinse and repeat

This has become a monster pain. There has to be a better way

Suspected Git workflow

1. Local copy will be my ‘master’
2. ‘Push’ files up to somewhere
3. ‘Pull’ files from this place in the middle to my live/testing server

I think I have an idea of how it should conceptually be done, but I don’t know how it should practically be done. Should I use a Github private repo in the middle? Is there a way for my Live site to “Pull” directly from my localhost repo?

Apologies if this seems elementary or beaten to death already, but I’ve searched and haven’t found a basic “This is how your workflow should look” guide.

With thanks!

Terry

回答1:

It looks like you're not using version control at all. It's a good idea that you're going to start. I just converted from SVN to Git, and I'm sort of doing what you're doing at a grander level. Let's start with your objectives:

1. Get version control
2. Establish some sort of web deployment via Git
3. Host the version control remotely

People will tell you that Git is not a web deployment tool - they may be right, but so far it is working ok for me, and I did something similar. Lucky for you, I practiced on a Wordpress install - here's the steps that I took.

1. Got everything with Git setup and installed as far as client goes.
2. Downloaded the latest version of Wordpress in a vanilla install.
3. git init the base install with no modifications
4. Branched the master into "dev" and "live"
5. Work locally, committing in "dev", then once changes are done, merged to live.

Now, what I ended up going back and doing was creating a gitolite server VM and using that as my host - this effectively replaced github in your example. I think you know the value of a remote repository - I would definitely pursue that route.

I'm going to backtrack for a second on step 2 of my recommendations. You should keep the vanilla version of Wordpress on the master so you can upgrade the core and see how it plays with your custom code, instead of upgrading the core on something like one of your branches and everything breaking. This has been pretty convenient for me, and something that I'm going to definitely use on larger projects like Magento.

Ok, back to the deployment. You could put a git client on your webserver and have it pull from its branch in the workflow - but you have to take some special planning considerations. Your prod files will most likely be different than your dev files in certain places, particularly configuration (database, etc) - you're going to want to make sure that those files are in .gitignore so you're not pulling up dev configs into your prod environment.

I've mostly summed up what people told me when I started working on this so I hope it helps. Again, I'm just slightly past where you are, so if anyone has any corrections/optimizations, please feel free to comment.

回答2:

I'm beginning to set up such a workflow for Wordpress. I already have it working for a few other web projects.

I'm using the gitolite (https://github.com/sitaramc/gitolite/wiki/) tool for managing bare repositories (repositories without a local checkout) in a central location, then triggering an update hook in gitolite when a branch is pushed from the development location.

This hook then ssh's to the live server (or client's account or whatever) with a shared private key stored on the deployment server, and does a git pull from the public_html or whatever location you have serving your Wordpress install.

This is done using a read-only entry in the gitolite config file which is conf/gitolite.conf in the local configuration repository. (Gitolite uses a git repository to manage it's config files)

repo wp-versions
  RW+ = tmzt
  R = server1
  R = server2

The first is my primary public key, which is stored keydir/tmzt.pub in the same repository (same format as .ssh/authorized_keys). The other two are live web servers which will have read-only access to the repository. Add the three keys to keydir and make sure to commit and push. The changes will be automatically made in the gitolite installation. (The server keys are shared by multiple users and copied to the .ssh/id_rsa file of each user, but this could www-data if you prefer).

RW+ means my primary user has read, write, and can update non fast-forward branches (useful for reverting commits on the server).