I’m not lucky enough to get to choose one source control manager and use it exclusively. On a daily basis I use git, svn, and hg. Every week or so I also use bzr. Luckily, I no longer have to touch darcs.
I haven’t dug in to the internals of these tools enough to say which one has the superior technical merits although I will say that I’ve never seen a git conflict resolution interface even across unbelievably hairy merges.
I write a lot of small libraries and a couple big ones. I care far more about the social effects and contribution workflows a tool provides than any other features. There are different public web applications that try and provide infrastructure for the social effects of DCVS and after months of working with different approaches I have to say that GitHub is the winner by a mile.
At the end of the day there are two factors that make GitHub such a clear winner. The first is zero friction publishing. The second is the democratizing effect of scraping any notion of a “central” repository.
Nearly a year ago i hit the Google Code project limit and had to call in some favors to get the limit pushed up for my account. I have to push lots of small libraries so having a simple and seamless publishing of repositories has made my life much easier. The fact that I can just push my repository and worry about turning that repo on GitHub into a “project” later, instead of the other way around, means that I have no reason **not** to publish every little thing I do.
The second and more controversial feature of GitHub, and possibly of git itself, is that there is never a clear central repository. There is my repository, and your repository, and every other **person’s** repository. This throws off FLOSS projects that have always relied on a “committer” hierarchy to manage the influx of work in to a project. Nearly every book on community driven open source focuses on the creation of a class of contributors with special write permissions to the repository. There has been a huge discussion on how to translate that process to DCVS and some tools, in particular hg, make it fairly easy to simulate older workflows with a central repository.
After living with GitHub for a while and seeing the potential for new collaboration I think the answer to translating the “committer” model to DCVS is to **not translate it at all**. GitHub makes **everyone** a committer and that enables a new class of contribution that the old model totally excluded.
Since code can travel seamlessly through different developer’s repositories each change takes on a life of it’s own. People who made what they thought were small changes for their own personal use easily share them with other developers and those changes can move around repositories hopefully making it in to an official release. New contributors don’t have to worry about this giant wall of process behind getting a patch in, they simply write the patch and push it, send pull requests to other relevant contributors and module owners eventually getting those changes pushed up in to the repository that gets packaged and distributed.
Someone is always going to be responsible for releasing a product, someone owns the keys to the distribution mechanisms, so I find the notion that some amount of authority over the project’s direction is lost by not centralizing the repository to be exaggerated. Although there is some authority that is lost to the previously defined class of committers the democratization of write permissions encourages a bigger class of lost contribution that is excluded by the laborious process of patches in bugs and the required upstream process to get the work committed. This also means that a number of contributors can live with changesets for an extended period of time before they get packaged in a release which increases confidence in large changesets that many projects reject outright for fear of instability.
GitHub solves the social problems of open source collaboration by taking a much more anarchist approach to the contribution process and while this is certainly shaking the foundation of traditional contribution models I’m loving it 
I enjoyed this article. I’ve noticed more and more how much I am finding interesting and useful projects landing on GitHub. It truly feels like a bazaar, the way the open source world was meant to feel, perhaps. It is vibrant and anarchic. What’s not to love?
Didn’t you try bitbucket.org? It’s similar to github but oriented to the Mercurial DVCS.
I have tried bitbucket.
I found it to be a little less obvious and not as well designed as GitHub but all in all a good effort.
My experience with git has been more positive than my experience with hg so I’m a little biased towards GitHub.
I also see a much larger community on GitHub. I’m following or have forked lots of repos on GitHub and I don’t have much more than an account on bitbucket. GitHub has an advantage here, hosting/coordinating git development is much harder than hg and there are limited OOTB solutions. Most of the project that I use hg for host their own service for coordinating development whereas I don’t work with a single project that hosts their own git service.