Git is a distributed (and soon decentralised) versioning or change tracking system, mostly used for managing software source code.

It was created 11 years ago with decentralised development in mind. Every copy of a repository contains the entire history of changes. Development can be done entirely offline and without the need to wait for slow servers. Occasionally these offline repositories need to be synchronised if working together with others. This was a giant step after centralised solutions such as CVS and Subversion.

Imagine a world where you had to wait up to 10–30 seconds to compare or to make changes. That was Subversion in the era of 1 Mbps broadband. With Git it happens in a fraction of a second.

This sounds pretty decentralised, doesn’t it? It is, save one small issue — copying and synchronising repositories.

Git is flexible in this matter. It has a concept called remotes, which are remote endpoints for synchronisation and they can use a variety of protocols. The two most widely used ones are Git over SSH and Git over HTTP — both are centralised.

Initially users had to install their own server software, many times augmented with a web viewer called gitweb. An obvious evolutionary step was the appearance of services like Github, Gitorious/Gitlab, Bitbucket, etc.

While these provide a wonderful service, they have the risk of single point of failure and censorship. Remember the denial of service attack against Github which rendered it unavailable for days? Remember that repositories can be removed based on copyright claims — which might be invalid and reported by malicious actors, yet the onus to prove they are not infringing is on the creator of the repository? And that governments can censor GitHub content?