I realize this may be a broad question on the surface, but I'm looking for specific examples of setups/workflows that people use to keep a version history of edited files on a WordPress site. For instance, when developing a site (and even after it's live), I often make changes to CSS and PHP files, but I don't have a great way of reverting to older versions of those files. For my purposes, making changes on a local development installation and then copying those changes over to the live site is often more trouble than I'd like. Any suggestions on how to get started using a versioning tool to track edits to files on a live site?
closed as off topic by Rarst♦ Oct 18 '12 at 17:32
Questions on WordPress Answers are expected to relate to WordPress within the scope defined by the community. Consider editing the question or leaving comments for improvement if you believe the question can be reworded to fit within the scope. Read more about reopening questions here.If this question can be reworded to fit the rules in the help center, please edit the question.
I am not sure how much you know about using version control, but I recently switched from SVN to GIT and find that to be great!
Though it depends in you live site's server has GIT installed (or will let you). I have a GIT setup on the live server also, running of a branch called something like
I would recommend putting some time it getting aquatinted with GIT (if you haven't already), I find it much easier and less hassle than SVN when it comes to changing / adding loads of files (and unlike SVN it doesn't put stupid
Sure, I am on a Mac, so sorry if none of these applies.
If I were to set everything up a new, I would do:
Setting it all up on the server can be a bit tricky, I have a MediaTemple and a Dreamhost account which both have GIT out of the box. The link in 5. tells you how to add a remote repo, do you dont have to do that until you want to bring your live site into the equation. I would recommend getting everything working locally first (unlike SVN, GIT doesn't require a remote repository, so you can bo everything on your machine for the time being)
I use SVN for version control with everything I do in WordPress development. I actually started this way because I needed SVN for plug-in development ... once I got started there, it was a natural extension to continue using SVN for themes and custom scripts on client sites.
Since plug-ins are already hosted on WordPress' server, I just check out a plug-in directly to the
Themes are a bit different, particularly when building for a client. I create a local repository (I have an
When I'm ready to publish the theme to a client's production server, I export the repository, zip it, and use the native Themes >> Add New functionality within WordPress. This works with custom plug-ins (that aren't hosted by WordPress) as well.
Like I said, I use WAMP on my local machine to run a development installation of WordPress. It works perfectly on my box and allows me to run as many instances of WordPress as I need for a particular project.
For SVN, I use Tortoise SVN. It's free, remarkably easy to use, and integrates with the file and command structure of Windows. Updating, committing, and exporting are all simple right-click, select command operations. Using "Export" allows you to send the entire folder (without the annoying
Manually transferring files can be a hassle, particularly if you keep changing one file but not all of them. If you instead FTP over the entire directory with "overwrite all" selected, it's much easier to replace old files (and you don't have to keep track of which changed and which didn't). It's like the old 5-minute installation WordPress used to have - just replace everything with the new version.
I like Aptana a lot, its has subversion integrated in and you can connect to your server with ftp/sftp easily and push files up, another great feature that it has is that if you create a new php project and include the "entire" WordPress folder (with wp-admin, wp-includes) you get code completion in your theme files.
In my setup the repo is local.
Personally, I think it is a fun exercise to install SVN / GIT and manage it, but if you can swing $15 per month, Beanstalk is worth every penny. They manage the whole server for you. http://beanstalkapp.com/ The FTP deployment tools are awesome. Mine automatically deploys the version to my staging server when I commit for example
Another way to get some personal file versioning is to use drop box. Every time you save a file into your dropbox it tracks the version, and you can restore to any previous version later on.. You and another developer, or group can share a drop box folder. Granted this does not do trunks, merges, etc, but it does make it very easy for a distributed team to work on one website. You just can not really work on the exact same files at once.
We keep our SVN working copy in dropbox, then I commit the files when the time is write. My designers will not commit files or deal with SVN, So this is the comprimise.
I prefer SVN because I do not need all the trunking that GIT is so great for and there are better GUI tools available of SVN.
You ask for "but I'm looking for specific examples of setups/workflows that people use to keep a version history of edited files on a WordPress site" but you also mention products :)
You get above as answer a list of tools and some best practices but I will focus here on the workflows: THEY ARE NOT WORDPRESS SPECIFIC:
But for the general examples/setups/workflows:
For starters: there ARE CM patterns, so independent of tooling. Google on CM Patterns, a lot of books out there, wiki's even communities e.g. http://www.cmcrossroads.com/forums.
There are also guides on setting up a valid stream strategy (google stream strategy), etc...
I don't think there is anything special about WordPress deployments compared to CM Management incl distributed parallel development on large Siebel, SAP, Informatica, Java etc.. factories. It's really almost default.
What is missing, I think, is that noone has writing a CMplan for WordPress development (yet) (IEEE). Once someone has done that (tool independent). The requirements can be filled in, I think, with any tool.
I think the reason that plan has not been written is that almost all WordPress implementations are still done by 1 person with a simple development-production setup so not with multiple developers/designers in the build phase having to deploy different versions that are running in the test environment, for instance.
the CMP plan starts with identifying all CI's in other words: make a list of all types of CI's present in a WordPress implementation including the apps, plugins, database, documentation, help, content, config files, release notes (!), etc...). That is a good start. Then decide which ones you want to bring under CM.
Next decide on what causes changes on these CI's e.g. a customer call for a bugfix, or an upgrade that is needed. If done right, this leads to a situation where you have the feeling things are under control.
Decisions like merging back from production to development and the way to handle that is part of that chapter (2 main patterns here) (though ofcourse you should try to minimize these hotfixes).
Only later look for a tool to do CM on one side (which includes version management as one of the tools) and change management tooling on the other side (which keeps you sane).
I think that is the best workflow to start with since, as far as I googled, noone has done yet. I think once the first person has written a WordPress CM Plan (according to IEEE) every other WordPress person in the world can copy that plan and make adjustments and implement the patterns in their tooling.
Isn't that too much work/too heavy : depends if you have a company or not: it can save your ass big time one day to have good CM plan.
I am on a shared host so I can't install SVN or anything like that. I use Mercurial to version-control on my home machine. I use Beyond Compare's FTP-sync to keep the local and remote folders in sync.
i'm using git. it's simple. you nly have to understand simple command such as clone, comit, push, pull and you're ready to go. that's the basic.
eventhough, if you use git it more such as coordinate a team to work on a products, then it's another level. but in the end, it worthed to use git or any version control. there're realiable when shit happen.