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 remote repo model

GIT Repository types

There are two types GIT repository:

  • Non-bare: a Git repository that has working directory with ".git" directory. It is created by "git init".
  • Bare: a Git repository that has no working directory, but with content of ".git" directory, nothing else. This makes sense because the shared remote repository is only used as a collaboration point, there is no reason to have a snapshot checked out on disk; it’s just the Git data. It is created by "git init --bare".

    • Protocols

    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.

    Example:

    Create the shared repository:

    It is a convention to create a shared repository with a directory name extension “.git”.

    $ cd /opt/git
$ mkdir my-project.git
$ cd my-project.git
$ git init --bare --shared

    Clone the repository from any host which can directly access the directory

    $ git clone /opt/git/my-project.git

    or

    $ git clone file:///opt/git/my-project.git

    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”.

    GIT remote repo example

    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”

    iot@sgbu-ucs-11:/opt/git-project$ mkdir my-project1.git
iot@sgbu-ucs-11:/opt/git-project$ cd my-project1.git/
iot@sgbu-ucs-11:/opt/git-project/my-project1.git$ git init --bare --shared
Initialized empty shared Git repository in /opt/git-project/my-project1.git/
iot@sgbu-ucs-11:/opt/git-project/my-project1.git$

    Note: we may need to add new users for each developer if this is a private repository:

    iot@sgbu-ucs-11:/opt/git-project/my-project1.git$ sudo useradd -g iot -d /home/iot1 iot1
iot@sgbu-ucs-11:/opt/git-project/my-project1.git$ sudo passwd iot1
Enter new UNIX password: iot1
Retype new UNIX password: iot1
passwd: password updated successfully
iot@sgbu-ucs-11:/opt/git-project/my-project1.git$

    Now we can clone the repository from another host as long as it can reach the server:

    sjc-ads-7727:/nobackup/weweng> ping sgbu-ucs-11
PING sgbu-ucs-11.cisco.com (172.27.126.61) 56(84) bytes of data.
64 bytes from sgbu-ucs-11.cisco.com (172.27.126.61): icmp_seq=1 ttl=55 time=0.492 ms
64 bytes from sgbu-ucs-11.cisco.com (172.27.126.61): icmp_seq=2 ttl=55 time=0.487 ms
^C
--- sgbu-ucs-11.cisco.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1146ms
rtt min/avg/max/mdev = 0.487/0.489/0.492/0.022 ms
sjc-ads-7727:/nobackup/weweng> 
sjc-ads-7727:/nobackup/weweng> mkdir x
sjc-ads-7727:/nobackup/weweng> cd x
sjc-ads-7727:/nobackup/weweng/x> git clone ssh://iot@sgbu-ucs-11:/opt/git-project/my-project1.git
Cloning into 'my-project1'...
iot@sgbu-ucs-11's password: iot
warning: You appear to have cloned an empty repository.
sjc-ads-7727:/nobackup/weweng/x> ls
my-project1/
sjc-ads-7727:/nobackup/weweng/x> cd my-project1/
sjc-ads-7727:/nobackup/weweng/x/my-project1> ls -lat
total 12
drwxr-xr-x 7 weweng eng 4096 Jan 13 16:55 .git/
drwxr-xr-x 3 weweng eng 4096 Jan 13 16:55 ./
drwxr-xr-x 3 weweng eng 4096 Jan 13 16:55 ../
sjc-ads-7727:/nobackup/weweng/x/my-project1>

    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:

    iot@sgbu-ucs-11:/opt/git-project/my-project1.git$ touch git-daemon-export-ok
iot@sgbu-ucs-11:/opt/git-project/my-project1.git$ ls
branches  config  description  git-daemon-export-ok  HEAD  hooks  info  objects  refs
iot@sgbu-ucs-11:/opt/git-project/my-project1.git$ sudo git daemon --reuseaddr --base-path=/opt/git-project/ /opt/git-project/ &

    In the client host:

    sjc-ads-7727:/nobackup/weweng> mkdir y && cd y
sjc-ads-7727:/nobackup/weweng/y> git clone git://sgbu-ucs-11:/my-project1.git
Cloning into 'my-project1'...
warning: You appear to have cloned an empty repository.
sjc-ads-7727:/nobackup/weweng/y>

    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.

    Enjoy!