6 Types of Git Protocols and Their Uses

It is the most simple protocol in Git, in which the remote repository is located in a different directory on the same host. This is commonly utilized if everyone on your team has access to a shared filesystem, such as an NFS mount, or if they all log in to the same computer, which is unlikely. 

The latter isn't ideal because all of your code repository instances would be on the same computer, increasing the chances of a catastrophic loss.

If you have a shared mounted filesystem, you can clone, push, and grab from a local file-based repository. To clone or add it as a remote to a current project, use the location of the repository as the URL.

You can execute something like this to clone a local repository, for example:

//srv/Git/project.Git $ Git clone

You might also try this to clone file with Git:

/srv/Git/project.Git

If you include the file:/ at the beginning of the URL, Git behaves slightly differently. Git uses hard links or directly copies the files it needs if you merely supply the location. If you use file:/, Git employs the mechanisms it normally uses to send data over a network, which are inherently inefficient. 

The major reason to use the file:/ prefix is if you want a clean copy of the repository with no unnecessary references or objects — for example, after importing from another VCS (Version Control System) (see Git Internals for maintenance tasks). 

We'll take the standard route because it's virtually always faster.

You can do something like this to add a local repository to an existing Git project:

$ Git add remote /srv/Git/project.Git local proj

Then, using your new remote local project, you may push and pull from that remote as if it were a network.

Git supports two types of communication over HTTP. There was just one way to achieve this prior to Git 1.6.6, and it was very easy and read-only. A new, smarter protocol was added in version 1.6.6, which allowed Git to intelligently negotiate data transfer in the same way it does through SSH. 

This new HTTP protocol has gained a lot of traction in recent years since it is easier for users to understand and connect with. The updated version is known as Smart HTTP, while the previous version is known as Dumb HTTP. We'll start with the newer Smart HTTP protocol.

Smart HTTP is quite similar to the SSH or Git protocols, but it runs over regular HTTPS ports and can use multiple HTTP authentication mechanisms, making it easier to use than SSH because you can use username/password authentication instead of setting up SSH keys.

It's arguably the most popular way to use Git presently, because it can be set up to serve anonymously, as with the Git:/ protocol, or with authentication and encryption, as with the SSH protocol. Instead of needing to create separate URLs for these things, you can simply use the same one. 

If you try to push then the repository prompts you for credentials (which it normally should). The same is true, for read-only access.

In reality, the URL you use to browse the repository online (for example, https://GitHub    .com/schacon/simpleGit) is the same URL you may use to clone and if you have access to a pushover too. 

If the host does not respond with a Git HTTP smart service, the Git user will attempt to rely heavily on the simpler Dumb HTTP protocol. The Dumb protocol anticipates a bare Git repository provided from the web server as normal files. The beauty of Dumb HTTP is how easy it is to set up. 

Simply place a bare Git repository beneath your HTTP document root and configure a specific post-update hook, and you're good to go (See Git Hooks). At that point, anyone with access to the web server where you've installed the repository can clone it.

When self-hosting using SSH, this is a common transport protocol for Git. This is because SSH access to servers is usually already set up — and if it isn't, it's simple to set up. SSH is an authenticated network protocol that is simple to set up and use due to its widespread use.

You can use an ssh:/ URL like this to clone a Git repository over SSH:

$ Git clone project.Git ssh:/[user@]server

For the SSH protocol, you can use the shorter scp-like syntax:

[user@] Git clone

server: project.Git

The Git protocol is the final step. This is a unique daemon included with Git that listens on a dedicated port (9418) and provides a service comparable to the SSH protocol but without any authentication. 

You must produce a Git-daemon-export-ok file in order for a repository to be provided over the Git protocol — the daemon will not serve a repository without it — but there is no extra security. 

Either the Git repository can be cloned by anyone, or it can't. This suggests that there isn't much pushing going on with this technique. You can enable push access, but because there is no authentication, anyone who finds your project's URL on the internet can push to it.