Kevin Schroeder has a new post for the Netbeans users out there wanting to work with the Zend Developer Cloud directly without having to mess around with other external software.

Getting NetBeans connected to the Zend Developer Cloud is actually pretty simple… if you have NetBeans 7.1 which is currently in RC. NetBeans 7.0 has a bug that won't allow you to connect to Git over HTTPS. NetBeans 7.1 fixes that issue. You will also need to make sure that you have the Git module installed.

His post includes the step by step process (including some screenshots to getting the automated deployment set up and working in this popular IDE. The key is setting up the SFTP connection to point to the right location on the cloud server (the path isn't very intuitive, he recommends finding it with another SFTP program for the initial setup).

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.

As is mentioned by Matthew Weier O'Phinney (and expanded on by Robert Basic) beginning immediately, the Zend Framework 2 project will no longer require developers to sign a CLA before submitting their code.

In #zf2 news, effective immediately, we no longer require a CLA for #zf2 contributions. Let the pull requests flow!

Robert gives a bit more detail in his post, pointing out the official git repo, the issues list, section on the wiki and the mailing list/IRC meetings. There's also a blog to follow to get the latest updates for the project.

If you'd like to find out more about this new version of the framework, check out this video from ZendCon by Matthew.

Kevin Schroeder has a quick tip for anyone using phpcloud.com and having trouble with git and "remote end hung up" error messages.

If you are using phpcloud.com and are experiencing errors with git [...] and you are trying to push large files (not sure what is defined as "large") you may need to change some git settings.

He points out two settings - one for Windows and the other for Linux - that increase the buffer size to handle larger files that might be included in your repository.

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!

Adam Peterson has posted an interesting idea for those out there running an internal staging server they want to constantly keep up to date with the main line of code (without manual intervention) - a git pull web frontend combined with git post-receive hooks.

This [move from svn to git] left a bit of a gap in my process where I could no longer test on a remote server without updating it manually by S/FTP or opening terminal and manually calling a git pull. Open terminal and manually git pull it did break up the work flow a bit so using the Dingo framework I created a very simple Git helper and gave it its own URL something like git/pull.

He added a post-receive hook to his git server that calls this "git/pull" URL on the staging server and updates the code on the server. This provides an easy asynchronous way to update things on another server. Note, though, that this should never be done on a publicly accessible server - it's a pretty large security hole (or at the very least made secure somehow). He used Dingo to create his interface, but something like the Slim micro-framework could have worked just as well. You can view his code on github.

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.

Recently the PHP project announced a move to git as the primary version control system for the language's development. In a new post to SitePoint's PHPMaster.com site, Davey Shafik explains what that means to the average developer and what you can expect of the future.

Just over two years since its move from the antiquated CVS to Subversion (SVN), PHP is once again on the move: this time, to Git. Well, eventually. The migration from CVS to SVN was a huge one and took many months. The need for the PHP project to support its user base, hook scripts (commit mailing list, etc.) means that any change of revision control software means quite a large commitment. This is why even though the voting is over, and the dust has settled, we won't be seeing PHP on Git until the end of this year.

Davey shares his vote - pro-git - and explains what his choice (and many others') means for the language, including a modified patch acceptance policy and a convenience for developers to be able to work anywhere.

All in all, I feel migrating from Subversion to Git can only be a good thing for the PHP project and the community as a whole. [...] it is pretty clear that the PHP development community is in favor of the decision.

A little while back, the PHP development group posted a survey of developers asking them which version control system they'd like to see the PHP project use. By an overwhelming margin, git has won and things are already in motion to move parts of the project away from subversion.

In his mailing list post, David Soria Parra explains:

After 2 weeks of voting and discussion, I closed the votes today. The results are fairly straightforward. Most of the users want to move to a decentralized version control system. [...] I don't want to make a difference of who voted for what. I think the results are overwhelming in favor of Git.

He'll be working on the spec to make the move for the PHP source over to git and is planning a cut over some time in December. Stay tuned to the php.internals mailing list for more details about the move as they come up.

The CodeIgniter blog has a a new update today with some changes that are happening in the project and it's community.

If you are following CICON 2011 today, then you no doubt already heard from the Reactor team: CodeIgniter is now using Git for source control, and has moved its home to GitHub. Also, CodeIgniter "Core" is not longer being publicly maintained. CodeIgniter "Reactor" is CodeIgniter, so we are dropping that suffix. In short: CodeIgniter is the framework, and Reactor is our community driven development program.

As a part of the move they also released a new version of the formerly-Reactor codebase. The EllisLab blog has more information about the git switch including their reasons and some of the immediate effects they see from the change.