But last week, he wrote the following about GitHub:
A centralized repository for a distributed version control system! Why didn't I think of that?
I think that he is way off base on this one.
Distributed version control systems are not incompatible with a centralized repository. You can use them with a centralized repository and most projects will still keep a central point for coordination of releases. In the Linux kernel project, for example, that central point is Linus tree.
The difference between a centralized VCS like Subversion and a DVCS is that you are not forced to use a centralized repository, and if there is one, its just a social decision, not a technical one.
I certainly agree that almost any project will want a "central" repository in the sense that you want to have one canonical default source base that people think of as the "primary" source base.
But that should not be a technical distinction, it should be a social one, if you see what I mean. The reason? Quite often, certain groups would know that there is a primary archive, but for various reasons would want to ignore that knowledge: [cut]
But even for smaller projects, the usual and recommended setup is:
- you clone from the agreed upon central repository: if you are starting a new project, congratulations, you are it. Just
git inita directory somewhere;
- you create branches to work on features;
- as they stabilize, you merge them into the master branch;
- you publish your repository somewhere for others to see your work;
- other fetch and merge from this public repository to their own repos;
- those others also keep a public repository somewhere.
Basically, you work on your own local repositories, you keep a public version of this repository somewhere online, and others pull from this one. Usually, unless you are on the same LAN you don't pull directly from each other private repos. You can do it sure, but its just not common, mostly because people usually work behind firewalls or NATs.
And a very good one at that.