If you're relatively new to using version control, there may be one technique you've yet to get a grip on. In this new post on SitePoint.com's Web blog they introduce you to using the "diff" functionality to discover differences between versions of code.

Every project is made up of countless little changes. With a little luck, they will finally form a website, an app, or some other product. Your version control system keeps track of these changes. But only once you understand how to read them will you be able to track your project’s progress. Using the example of Git, the popular version control system, this article will help you understand these changes.

They include several screenshots and line-by-line descriptions of what each part of the output of the "git diff" command is. There's also a brief description of what each of the sections contains and how to inspect both committed and non-committed changes. There's even a link to a list of other applications that may help provide a clearer picture of the changes rather than just the command line output.

On the SitePoint PHP blog today David Shirley has a new tutorial looking at continuous deployment with a bit more detail than his previous post.

In an earlier article I talked about what Continuous Deployment was and how it fits into the modern programming process. We took a small swipe at how it works, but some people (okay, one person) felt that I could have gone into more detail and they were right. [...] The essence of Continuous Deployment is that you use automated tools to do a lot of the heavy lifting. This means there may or may not be a bit of a learning curve when you first get started. A number of software elements are brought into play, and if you already know how to use those, great. If you don’t, just remember that this is a learning curve, not a barrier.

He's broken down the rest of the tutorial into sections relating to the different pieces needed to effectively set up a continuous deployment (CD) system:

• Effective use of version control
• Commitment to automated testing
• Setup and use of automated build software

On PHPMaster.com today there's a new article from Martin Psinas about moving to cloud-based development for your PHP applications (using online editors that can potentially replace your local development tools).

I knew going into this purchase that the Chromebook was designed without a hard drive and is intended more for casual web surfers rather than power users, but that didn’t stop me. I also knew I wanted to take full advantage of the Chromium OS as an on-the-go platform so installing a LAMP-based development environment or tinkering with the system would just defeat the purpose. I decided it was time for change, time for liberation!

He talks about some of the basic concepts behind the move to a cloud-based environment and working with various aspects of development there. He covers things like version control, finding a place to store his code and choosing an IDE. He links to a few options including ShiftEdit, CodeEnvy and Cloud9 (his choice).

if you're still not using any kind of version control in your development projects, you're really doing yourself (and your fellow developers) a disservice. Lorna Mitchell wants to help nudge you down that road. To do this, she's provided a whitepaper about version control systems - what they are, how they're helpful and some cool stuff you can do with them.

Last week I wrote an email to a client who hasn't yet implemented source control, but who is thinking about it. It turned into rather a long email as I attempted to convey WAY too much information in one long email. After some twitter banter, I repackaged my thoughts into a whitepaper on Source Control entitled You're not using source control? Read This! (PDF, no registration needed).

The whitepaper looks at three different tools - Subversion, git and Mercurial (Hg) - and includes a "sales pitch" you can give to the people involved in your project about how it can help them. There's also a few helpful links included at the end for more information about each piece of software.

In this latest post to his blog Stefan Koopmanschap shares a quick tip about using the git-svn tool with the dependency installer in a Symfony2-based application.

I work a lot with Symfony2's deps file for installing 3rd party bundles into my project (yeah I know, I should be using Composer, right?). This works really well when working with pure Git. However, when you're not using Git on it's own but instead use git-svn, you may run into some issues when issuing git svn dcommit,

One issue relates to a "Failed to read object" error that could come up during the push. His solution involves a few steps (manual ones) to prepare those bundle directories and make it easier to push the rest of your changes. He also includes a few links to other resources that he found around the same topic.

If you haven't gotten a chance to try out git for your version control system, now's the perfect time. PHPMaster has an introduction to using git for a simple PHP project. It introduces you to some of the basics and gets you up to speed quickly.

Some of the more commonly used version control systems that you have likely heard about are CVS and Subversion. This tutorial will take a "forget everything you know about CVS or Subversion" approach. As someone who has used all three of these systems in the professional realm, I can testify that some knowledge of CVS or Subversion can be useful when approaching Git, but it is not necessary. The best way to learn Git is to start using Git for what Git is.

They break it up into a few different sections - why use git, how to create a new repository, adding/staging files for commit, viewing the project history and viewing diffs for different versions. This is the first part in a series, so keep tuned for future parts touching on branching, merging and working with remote repositories.

The Seattle PHP User Group is having this month's meeting tonight (the 3rd) starting at 6:30pm at Market Leader, Inc featuring talka from Brian Swan on "PHP on Azure" and Jesse Keating on "Git".

Market Leader,Inc. is graciously hosting the venue for Seattle PHP Meetup in Kirkland, WA this month!! In fact, Ariz Jacinto (long-time member & frequent presenter at our Meetups), an employee of Market Leader, Inc., has gone bonkers and lined up a killer night for us all! Note the entrance and then celebrate the FREE PARKING!!

Brian Swan is a Microsoft advocate for PHP on Windows and Jesse Keating is the release engineer for Fedora Core. There's still time to RSVP on Meetup and attend this event - be sure to sign up so they know how many to expect!

Phil Sturgeon has a new post to his blog today for the CodeIgniter folks out there - a tip on keeping things organized by using git submodules for package management.

With CodeIgniter moving to GitHub we are starting to see a lot of CodeIgniter developers wanting to learn more about Git, specifically how they can use it to improve their workflows, manage their applications and move away from the horrible days of copying and pasting updated libraries off a wiki. UCK. Sparks are helping us on the whole, but there is another method that we can use to manage our packages: Git Submodules.

Submodules allow you to pull in source from a remote repository without having to merge the code into your own. It creates a dependency between the two and makes it easier to check out only what you need. He gives the example of his oauth2 package being needed in multiple other applications, so instead of including and checking in multiple versions, he made a separate repo and defined the source as a submodule. He also includes a bit about fixing issues in your submodules with a few handy commands to get on the right branch, add a remote and push the commit.

In his latest post to his Web Species blog Juozas Kaziukenas looks at dependency management in PHP applications and offers a few suggestions of how you can make them easier to track.

Rarely a project lives by itself, especially in the days of frameworks. Furthermore, there are a lot of great open source libraries you might want to use to save time. But all of this raises a new problem - how could we manage all those dependencies. Here are some thoughts on this problem and how you might want to solve it; without shooting yourself in a foot.

He mentions svn:externals and git's submodule as options in version control systems, PEAR for package management, Apache Maven and the deps file in the Symfony framework.

Pim Elshoff has a recent post to his blog looking at a "kickass development environment" he's gotten working on Windows that includes PEAR, some type of version control (git or svn - take your pick), Ant for builds and Jenkins for continuous integration.

Recently I have become quite interested in quality assurance. Not that many things are going wrong for me, but I’d really like to be more certain about the quality of my work. I’ve used some tools to help me achieve just that. In less than two hours you can set up your workspace and have the living daylights automated out of you!

He provides a full guide to getting the full stack set up including the command-line calls you'll need to make, creating a new build file for Ant and setting up the PHP tools (like Phpmd, DocBlox and Pdepend). In the end, you should see something similar to this setup in your Jenkins build.