I am a programmer and architect (the kind that writes code) with a focus on testing and open source; I maintain the PHPUnit_Selenium project. I believe programming is one of the hardest and most beautiful jobs in the world. Giorgio is a DZone MVB and is not an employee of DZone and has posted 638 posts at DZone. You can read more from them at their website. View Full User Profile
I always believed in Subversion's
potential and that it would be a wide improvement over the nightmare
that was CVS,
but I found out that, as Linus says, There is no way to do CVS right.
Subversion is fairly good and it's probably the better centralized
version control system on the market, and it's open source. But after
my first day of Git real-world usage, I
now cannot negate that the distributed model of Git will be superior at
For example, in Git, you are not forced to have a remote repository:
you can start with your local repository, and commit to it. No need to
set up server software if you don't want to, as your machine is already
your own server.
After working locally for some time and having done very fast
commits as you usually did much more slowly with your remote Subversion
server, you can push or pull changesets to other
repositories. I was worried about the inherent uncertainty in this
process (which branch? Which repository?), but Git tracks the origin of
your repository, precisely the common ancestor in the remote branch,
which your master branch was forked from. When you start by cloning a
remote repository (as it is almost always the case), it will push to
that origin. But you can also push to nearly everything, even if there
is not a common ancestor.
The converse is true: you can also pull to update your repository from
an external one, that may be your point of convergence. Obviously, you
can also pull from everywhere, in a local branch if you are not sure to
incorporate the changes.
The commit access notion vanishes in Git. You and I typically do
not have commit access to major projects such as Zend Framework or
Doctrine anyway (ok, I have to Doctrine, but when I come out with a
small patch I just put it the bug tracker for a review), and we have
only our working copy, having to upload patches to the bug tracker.
Multiple versions of those patches. That quickly become not in sync with
the current revision of the codebase.
Collaboration between working copies is difficult, as an official branch
is needed. Moreover, it's rare that you know a branch is needed ahead
of time. If for every feature you started a remote branch, even with
Subversion (which has cheap copy-on-write
branches) the development would be very slow. So many times you end up
working on the trunk and struggling because you cannot break it, and
sending patches by email. These problems are described in Linus's talk at Google
about Git - which is amusing. When I watched his talk using Subversion
really started bugging me; I knew that here was an alternative, and it
consisted of mature software since the talk was old, from 2007.
What's the solution then? In Git everyone has his own repository, so you
can just pull changes from other people and pushing changes to them.
There is no commit access, only a group the lead developer trusts and he
will pull from. This group may pull and review from other people, in a
hierarchical work flow where a chain of trust is established. For an
open source project, Git is worth its weight in gold (which actually I
don't know, but it will be surely expressed in hexadecimal.)
You can break your repository if you want, committing all the day
without problems, and being able to revert to every commit's revision
as if Git were a time machine, and very cheaply (in Subversion
you are forced to hit the network to revert to revisions older than the
last commit.) When you have fixed your copy after ten, twenty or an
hundred commits and all tests are passing, you may finally push.