GIT is becoming very popular. It is an excellent SCM tool. I really like it because it is easy to use, designed with distributed architecture, with a local repository available. It is also flexible that you can simply use it without central repository. However for big projects, it always has central repository which is hosted in server, and allows many developers to work in the same time.
GIT Repository types
There are two types GIT repository:
In order to communicate the remote respository, a protocol is needed. Git can use four major protocols to transfer data: Local, HTTP, Secure Shell (SSH) and Git.
1. Local Protocal
The most basic protocol is the Local protocol, in which the shared remote repository is in another directory, which is typically NFS mounted, unless all users use the same host, in this case it can be just a local disk attached to the host and mounted.
Create the shared repository:
It is a convention to create a shared repository with a directory name extension “.git”.
Clone the repository from any host which can directly access the directory
This approach is easy and quick. The issue could be that you have to mount to access the GIT repository directory.
2. SSH protocol
This is the protocol I really like because SSH access to servers is already set up in most places – and if it isn’t, it’s easy to do. SSH is also an authenticated network protocol; and because it’s ubiquitous, it’s generally easy to set up and use. In fact, it is not much extra steps comparing to “local protocol”.
Example: let’s say I have a UCS server “sgbu-ucs-11”, which is chosed as GIT server, has a lot disk space. See below how to create a remote shared GIT repository “/opt/git-project/my-project1.git”
Note: we may need to add new users for each developer if this is a private repository:
Now we can clone the repository from another host as long as it can reach the server:
Now the user can develop using the clone repository as usual.
With SSH protocol, it is easy to use except that it doesn’t support annoymous clone. This can be a serious issue if the repository is a popular open source project. For that GIT protocol can help.
3. GIT protocol
Git protocol. This is a special daemon that comes packaged with Git; it listens on a dedicated port (9418) that provides a service similar to the SSH protocol, but with absolutely no authentication. In order for a repository to be served over the Git protocol, you must create the git-daemon-export-ok file – the daemon won’t serve a repository without that file in it – but other than that there is no security. Either the Git repository is available for everyone to clone or it isn’t. This means that there is generally no pushing over this protocol. (https://git-scm.com/book/en/v2/Git-on-the-Server-Git-Daemon)
Example: enable GIT access for the repository my-project1.git in the server:
In the client host:
4. HTTP protocol
Git can communicate over HTTP, it is popular for larg and official repository. But it requires to have HTTP server in place, which is not hard to do. For more details, check https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols.