Getting Started with Subversion, Git, or similar Version Control System to keep a History of my Files?

5 Views

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?

Post Views: 5

Related posts

Leave a Reply

7 comments

  1. 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 off a branch called something like production. Whenever I finish implementing/fixing something locally, I merge it into the production branch, then SSH into the live site’s server and pull in the changes. Beats dragging files over FTP when you never know if you are overwriting changes etc.

    I would recommend putting some time in getting acquainted 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 .svn folders everywhere).

    I am on a Mac, so sorry if none of these applies, but I use Coda as a code editor and installed Git through Ports (using Porticus).

    If I were to set everything up anew, I would do:

    1. Install Coda

    2. Install Porticus (which will require you to install Ports, but there is information on that page)

    3. Once you have installed Porticus, open it open, search for “git-core” and Install that.

    4. Download and Install GitX 7-5

    5. There is a good guide on setting up a git repo here, but at it’s basic: 1. Open Terminal. 2. cd to where you want your site to reside. $: mkdir mysite && cd mysite 3. $: git init and thats it! If you add files to this folder then continue to the next step

    6. Once you have set up a GIT repository locally (above article) then if you open that directory in GitX you will be able to commit stuff etc etc.

    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 step 5 tells you how to add a remote repo, so you don’t 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 do everything on your machine for the time being).

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

    Plug-ins

    Since plug-ins are already hosted on WordPress’ server, I just check out a plug-in directly to the /wp-content/plugins/ directory of my local WordPress installation (I run WAMP on my development box). Then I make changes to my local copy and, when it’s ready for showtime, commit to the repository. It’s a smooth process there, no uploading/downloading and instant verification that my changes worked.

    Themes

    Themes are a bit different, particularly when building for a client. I create a local repository (I have an R partition on my hard drive specifically for this purpose) and check out the empty repository directly to my /wp-content/themes directory. Then I make changes as needed and develop until it’s ready, committing revisions as I go.

    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.

    Tools

    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 .svn folders) directly to any location of your choice – I frequently export to the desktop. Zipping the folder is also a right-click operation, and WordPress handles the upload.

    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.

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

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

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

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

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