DeGit是一个去中心化的Git项目托管平台

DeGit是一个去中心化的Git项目托管平台

Linux 其它

访问GitHub主页

共101Star

详细介绍

DeGit is a decentralized Git projects hosting platform. You can join by starting a node and pointing your browser at 127.0.0.1. Then, just work with it as if it was GitHub. There is no central point of failure, since the network of DeGit nodes is run by anonymous volunteers.

To start, simply do (it uses your .ssh/id_rsa for authentication):

$ gem install degit
$ degit run

In a few seconds you can open https://localhost:8080 and enjoy the system, which is very similar to GitHub. You can, of course, use local Git repo, which is on-fly synchronized with other DeGit nodes.

Motivation and Related Works

We are not the first who are thinking about a decentralized solution for hosting and managing of Git repositories. There were a few similar products created before (if you know anything else, please submit a pull request):

Even though GitHub, GitLab, BitBucket, Phabricator, SourceForge, CodeCommit, and Gitee are great platforms, they have three critical drawbacks:

It seems that the need for a decentralized solution is obvious. We believe that the community would enjoy having a platform with the following features:

  • Pull requests, stars, and followers,
  • GitHub-like web user interface,
  • Entirely free for public and private repositories,
  • Not owned by anyone,
  • Moderated by the board of deputies.

How It Works?

The following principles are behind the architecture of DeGit:

  • An author is the owner of a node, authenticated by his/her RSA key
  • A repository is a combination of 1) Git files and 2) immutable stories
  • A story is an issue, a comment, a pull request, a star, a wiki page, etc.
  • Issues, PRs, and comments have hash codes instead of sequential IDs
  • Each story is RSA-signed by its author
  • Each node decides for itself which repositories to host
  • Give-and-take principel is in place: "The more you host for me, the more I host for you"
  • Commits are announced to neighbour nodes, which they can git pull later if they want
  • Conflicts are resolved through DeGit Consensus Algorithm (see below)
  • Neighbours-discovery protocol is similar to the one used in Zold
  • Nodes communicate through HTTP RESTful interfaces

DeGit Consensus Algorithm based on Proof-of-Availability (PoA):

  • A branch dominates during merge if the providing node is more available
  • The availability of neighbours is subjectively judged by each node
  • Commits from less available branches are ignored during merge
  • The availability of itself is configurable (either MAX or MIN)

It is highly recommended to avoid making parallel commits to the same branch, since it may lead to inability to merge and abandonded (or lost) branches.

Here is how the data is propagated when you interact with Git on your laptop:

  • You git commit your changes to your branches
  • You do git push to your localhost
  • Built-in post-commit hook pushes commits to your neighbour nodes
  • Some neighbours break the connection and ignore the data
  • Others attempt to merge the coming data with their local repositories
  • They resolve conflicts according to the Consensus Algorithm (MAX)
  • You get "OK" if all conflicts are resolved in your favor, "ERROR" otherwise

This is what happens on a node:

  • New commits arrive from the client
  • We git merge them to the existing repository
  • Conflicts are resolved according to the Consensus Algorithm (MAX)
  • We git pull all neighbours
  • Conflicts are resolved according to the Consensus Algorithm (MIN)

How to Contribute?

Just give us a star and wait. We'll update this page soon.

推荐源码