Our intention was simple — enable people to openly collaborate on projects that could turn into startups. Groups would be open, dynamic, and grow with the popularity of a project.

We needed a place to store our code. The fork and pull model did not meet our needs so integrating with GitHub was not an option. Our proposed access model required branch level permissions. A makeshift Gitolite solution proved to be buggy, difficult to test, and hard to setup.

Building our own git server was the best option. Our main requirement was that it would need to enforce branch level push permissions. Additionally, credentials such as public RSA keys would need to be stored in the database.

Tasked with building the Git server, I quickly found myself knee-deep in Twisted’s source. Several SSH RFCs helped me piece it together. While specifications of Git’s transfer protocols helped guide me towards a suitable solution. What follows is a distillation of what I learned.

Connections — Protocols, Factories, Services

With some Twisted basics we can make the server listen. Protocols are used to manage a connection and receive data. Connections are represented by ITransport implementations.

With a buildProtocol method Factory instances create Protocol instances for each connection. A service is used to bind a Factory instance to a port.

SSHFactory is the base factory class for SSH. It has to be extended to provide the host keys used in the SSH handshake. The Key class represents RSA or DSA keys.