Question

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

Answer 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.