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.
Why did I vote for Git?
Having followed the same migratory route as PHP for my own versioning needs, starting from CVS and moving to Subversion and then most recently to Git, I have experienced first hand the benefits each of these systems brings over their predecessors.
Subversion (at least at v1.5 when I last used it) had very poor branch management. For existing repositories, the ability to use merge tracking was non-existent in any meaningful way, and even just with a small team we often had large, complex conflicts to resolve. While Git does bring a whole new way of thinking to the table, for me its branch management alone was worth the move away from Subversion.
What does this mean for PHP?
With the move to Git and its superior ability to create and merge branches, there is now a lot of flexibility available to the developers of PHP for both making and accepting contributions. Rather than the traditional development model of making a plan and sticking to it (hah!) with all developers working in the same branch (i.e. HEAD), developers can work at their own pace in their own branches and then come to a consensus on which of their branches will comprise a given build.
Such branch merging could be a potentially huge shift in the development cycle of PHP as it makes many options available to the team. For example, they can continue as they have been or they can choose to switch to a quarterly or bi-annual release cycle. They could even choose to do releases more often, pushing out features immediately as they become stable. If a feature isn’t ready yet, just don’t merge it in.
Additionally, Git offers s a lot more convenience for the core developers, many of whom travel all over the world and will benefit from the “commit locally while stuck on a plane” scenario that distribute version control systems afford. And let’s face it, anything we can do to make the core developers lives easier is beneficial to the project.
What does this mean for you?
If you haven’t already, you need to start brushing up on your Git skills. I’m sure we will see, if not an official clone, the PHP repository on GitHub sooner rather than later, making it all the easier to fork the repository and contribute changes.
With the potential change in development cycles, it could also mean new features reach you much faster — with the caveat the majority of virtual hosting companies will lag behind (traits anyone?).
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. And judging by the voting results, the move to Git may be controversial (though I think it’s fairer to say the move away from Subversion is what fueled any controversy), but with 78 votes in favor of migrating and 52 of them choosing Git, it is pretty clear that the PHP development community is in favor of the decision.
Image via marema / Shutterstock
Davey ShafikDavey Shafik has been developing the web for over a decade; author of 3 books and many articles and a veteran conference speaker, he is proficient in all aspects of LAMP development from front-end to kernels. He lives in sunny Florida with his wife and 6 cats.
