I often still use Google Code Project Hosting service to keep my public repositories. In this age where GitHub is very popular, I often get asked why I bother to do that and not just stick with GitHub. Here is a short explanation.
The first motivation is to avoid intentional centralization. Git is distributed, there is no master server. I can always push my repository to any place I want, thereby creating an automatic mirror in case one server is down. It is ironic if people do not work during any GitHub outage. For a start, you can always work offline as that is the main benefit of Git at the first place. In addition to that, code collaboration can still be carried out using any remote repository everyone can push to and pull from. There should not be any single point of failure in modern software craftsmanship.
Another advantage of Google Code is its online Git viewer. With GitHub as of today, you can get the branches overview via the graph visualizer. For my preference, I still think Google Code’s way of visualizing the relation between various branches is more useful to the project maintainer. It also follows the standard of various client-side version control tool. For Google Code, this is not specific to Git. Even if you choose to use Mercurial, you will get the same feature. It was available since Google Code only supported Subversion a long time ago.
One very useful aspect of Google Code viewer is the ability to see every change as a side-by-side diff. After all these years, I can’t believe that GitHub still does not have it. Even Gitorious and BitBucket give that choice of side-by-side view.
As I mentioned many times before, I really like GitHub. There seems to be just few remaining issues before it can be the ultimate collaborating tool. Beside the above concerns with its repository viewer, I hope some day GitHub will also address the lack of searchability and a way to enforce contribution rules. Surely everyone wants the one-hub-to-rule-them-all, right?