Skip to main content

Services

By now, you should have a way to use Git for your day-to-day work. However, in order to use the collaborative features of Git, you also need to have a remote Git repository. While you can technically push and pull from your personal repository to make changes, this is discouraged because it's easy to mix up other people's progress if you're not careful. Also, you want your collaborators to be able to access the repository even when your computer is not online - it is useful to have a more reliable public repository. So the best way to collaborate with others is to set up a shared repository that you and your collaborators have access to, and from which you can push and pull data.

Setting up a Git server isn't hard. If you don't mind hosting your code on someone else's server and don't want to go through the hassle of setting up and maintaining your own server, try a third-party repository hosting service.

A remote repository is usually just a bare repository - a repository that doesn't have a current working directory. Because the repository only serves as a collaborative medium, there is no need to check for snapshots from disk; all that is stored is the Git material. In short, a bare repository is a .git subdirectory within your project directory. subdirectory of your project directory, and contains no other material.

Git Protocols​

There are four different protocols that Git can use to transfer material.

  • Local protocol (local)
  • HTTP protocol
  • SSH (Secure Shell) protocol
  • The Git Protocol

Local protocols​

The most basic of these is the local protocol, where a remote repository is just another directory on the same host. This is common when each member of the team has access to a shared filesystem (such as a mounted NFS) or, less commonly, when multiple people share the same computer. The latter is not ideal, as all your code repositories are more likely to be lost catastrophically if they are stored on the same computer for a long time.

  • Advantages

The advantage of a filesystem-based repository is that it is simple and uses existing file permissions and network access rights directly. If your team already has a shared filesystem, setting up a repository is easy. Just put a copy of the bare repository in a path that everyone can access and set up read/write permissions, just like you would any other shared directory, and you're good to go. We'll discuss how to export a bare repository when we set up Git on the server. This is also a quick way to pull updates from someone else's working directory. If you're working on a project with someone who wants you to pull updates from the repository, it's much easier to run something like git pull /home/john/project than to push it to the server and grab it back.

  • Disadvantages

The downside to this approach is that shared file systems are often harder to configure and this is less convenient to access from multiple locations than a basic network connection. If you want to push content from home, you must first mount a remote disk, which is inconvenient to configure and slower than network-connected access. It is worth noting that this method is not necessarily the fastest when you are using a file system similar to a shared mount. Accessing the local repository is the same as the speed at which you can access your data. On the same server, if you allow Git to access your local hard drive, accessing the repository via NFS is generally slower than accessing it via SSH. Ultimately, this protocol does not protect the repository from accidental damage. Each user has full shell access to the "remote" directory, and there is no way to prevent them from modifying or deleting internal Git files and corrupting the repository.

HTTP Protocol​

Git has two modes of communication over HTTP: Smart HTTP, and Dumb HTTP. The

Smart HTTP Protocol​

Smart HTTP works like SSH and Git, except it runs on the standard HTTP/S port and can use various HTTP authentication mechanisms, which means it's much easier to use than SSH, for example, you can use HTTP username/password authorization and not have to set up an SSH public key.

Dumb HTTP protocol​

If the server does not offer the intelligent HTTP protocol, the Git client will try to use the simpler "dumb" HTTP protocol. In the dumb HTTP protocol, the web server treats the bare repository as a normal file and provides file services. The beauty of the dumb HTTP protocol is that it is easy to set up.

  • Advantages

We will only focus on the advantages of the Smart HTTP protocol. The simplicity of requiring only one URL for different access methods and the fact that the server only prompts for authorization information when it is needed makes Git very easy for end users to use. The ability to use username/password authorization is a big advantage over the SSH protocol, so that users don't have to generate an SSH key pair locally and then upload the public key to the server before using Git. The availability of the HTTP protocol is a major advantage for non-experienced users, or users who do not have SSH-related programs on their systems. Similar to SSH, the HTTP protocol is also very fast and efficient. You can also provide a read-only repository service over the HTTPS protocol, so that you can encrypt data when transferring it; alternatively, you can even have the client use a specified SSL certificate. Another advantage is that the HTTPS protocol is so widely used that the average corporate firewall will allow data through on these ports.

  • Disadvantages

On some servers, setting up the server side of the HTTPS protocol can be a little trickier than the SSH protocol. Other than that, there is little advantage to using other protocols to provide Git services over the intelligent HTTP protocol. If you're using push with authorization over HTTP, managing credentials can be a bit trickier than using SSH key authentication. However, you can choose to use a credential storage tool such as Keychain for macOS or Credential Manager for Windows. See Credential Storage for how to securely store HTTP passwords.

SSH Protocol​

The SSH protocol is commonly used as a transport protocol when setting up a Git server. This is because most servers already support SSH access in most environments - even if they don't, it's easy to set up. SSH is also a network protocol for authenticating authorizations; and, because of its ubiquity, it is easy to set up and use.

  • Advantages

The advantages of using the SSH protocol are many. Firstly, SSH is relatively easy to set up - the SSH daemon is common, most administrators have experience with it, and It and its associated management tools are included in most operating systems. Secondly, access via SSH is secure - all data transferred is authorised and encrypted. Finally, like HTTPS, Git and local protocols, SSH is efficient and tries to compress data before transfer.

  • Disadvantages The downside of the SSH protocol is that it does not support anonymous access to Git repositories. If you use SSH, then even if you are just reading data, the user must access your host via This makes the SSH protocol a disadvantage for open source projects, as people may only want to clone your repository and look at it. If you are only using it on a corporate network, SSH may be the only protocol you use. If you want to provide both anonymous read-only access and the SSH protocol, then you'll need to set up a service that others can access, in addition to setting up an SSH service for your own push.

Git Protocol​

This is a special daemon included in Git; it listens on a specific port (9418), similar to an SSH service, but requires no authorization to access it. To make the repository support the Git protocol, you need to create a git-daemon-export-ok file - this is required for the Git protocol daemon to serve the repository - but otherwise there is no security measures. Either anyone can clone the repository, or no one can. This means that you can't usually push through the Git protocol. Since there is no authorization mechanism, once you open up the push operation, it means that anyone on the network who knows the project URL can push data to the project. Needless to say, very few people will do this.

  • Pros

Currently, the Git protocol is the fastest network transport protocol used by Git. If your project has a lot of access, or if you have a large project and don't need user authorization to write, it's a good idea to set up a Git daemon to serve it. It uses the same data transfer mechanism as SSH, but eliminates the overhead of encryption and authorization.

  • Disadvantages

The downside of the Git protocol is the lack of an authorization mechanism. It is not advisable to use the Git protocol as the only means of accessing a project's repository. It's common practice to provide both SSH or HTTPS access to the project repository, and only give push (write) access to a few developers, while everyone else has read access via git://. The Git protocol is also perhaps the most difficult to set up. It requires its own daemon, which requires configuring xinetd, systemd, or some other program, which is not easy to do. It also requires the firewall to open port 9418, but corporate firewalls don't usually open this non-standard port. Large enterprise firewalls will usually block this port.

Third party hosting​

There are many more modern, full-featured Git servers out there, GitLab being one of the best known, and GitHub and Gitte are great open source communities.