> Oh, let's dance around laughing because github does not enforce anything. It's surely better than actually looking at how people end up using github in practice.
People use github in as many different ways as people use git.
For example, I often use github repositories as a read-only central repository, on top of which I have a few local changes. Then I periodically sync with "git fetch origin && git rebase origin master". Maybe I'll read the new entries of "git log origin --not master" before rebasing. This is nearly the way I'd use a centralized CVS.
Other times I'll add several github repositories as remotes to a local repository. (Such as on the bitcoin project, where several developers have their own repositories where they push experimental changes.) Then I can switch between their code and mine and cherry-pick to my heart's content.
With my own code, I start working with local git repositories -- well, local in the sense that the "origin" remote lives on my backup server. Then if I want to publish things, I can just set up a github repo, add it as a remote, then push things to and from there. When people send me pull requests or patches, I can pull them to the local system and rearrange them, then push them to the github remote.
Besides, Github itself has pretty buttons for managing pull requests between different github repositories, and also has key management tools if you want to let people push directly. So they go further than just "not enforcing anything" and actively support different workflows.
The only times I use git in such a simple way that svn could handle it, I'm using "git clone" as a shortcut for wget and tar -- that is, I'm not controlling the source code at all.