There is a misunderstanding here with respect to what a “fork” is. A fork is in fact nothing more than a set of per-user branches. When you push to a fork you actually do push to the original repository, because that is the ONLY repository.

You can try this out by pushing to a fork, noting the commit and then going to the original repository and using the commit ID, you’ll see that the commit is “in” the original repository.

This makes a lot of sense, but it is far from obvious (I only discovered this accidentally recently).

When John forks repository SuperProject what seems to actually happen is that all branches in the source repository are replicated with a name like “John.master”, “John.new_gui_project”, etc.

GitHub “hides” the “John.” from us and gives us the illusion we have our own “copy” of the repository on GitHub, but we don’t and nor is one even needed.

So my fork’s branch “master” is actually named “Korporal.master”, but the GitHub UI never reveals this, showing me only “master”.

This is pretty much what I think goes on under the hood anyway based on stuff I’ve been doing recently and when you ponder it, is very good design.

For this reason I think it would be very easy for Microsoft to implement Git forks in their Visual Studio Team Services offering.