Git on the Server

A remote repository is generally a bare repository — a Git repository that has no working directory. Because the 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. In the simplest terms, a bare repository is the contents of your project’s .git directory and nothing else.

The protocols

Git can use four major network protocols to transfer data: Local, Secure Shell (SSH), Git, and HTTP. 

Local protocol

The most basic is the Local protocol, in which the remote repository is in another directory on disk. 
Git operates slightly differently if you explicitly specify file:// at the beginning of the URL. If you just specify the path, Git tries to use hardlinks or directly copy the files it needs. If you specify file://, Git fires up the processes that it normally uses to transfer data over a network which is generally a lot less efficient method of transferring the data.

SSH protocol

SSH is also the only network-based protocol that you can easily read from and write to. The other two network protocols (HTTP and Git) are generally read-only.
To clone a Git repository over SSH, you can specify ssh:// URL like this:

git clone ssh://user@server:project.git

Or you can use the shorter scp-like syntax for SSH protocol:

git clone user@server:project.git

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-export-daemon-ok file — the daemon won’t serve a repository without that file in it.
The Git protocol is the fastest transfer protocol available. Generally, you’ll pair it with SSH access for the few developers who have push (write) access and have everyone else use git:// for read-only access.

HTTP/S protocols

To set it up is simple. All you have to do is put the bare Git repository under your HTTP document root and set up a specific post-update hook. To allow read access to your repository over HTTP, do something like this:

$ cd /var/www/html/git/
$ git clone --bare /path/to/test    test.git
$ cd test.git
$ mv hooks/post-update.sample   hooks/post-update
$ chmod a+x hooks/post-update

The post-update hook that comes with Git by default runs the appropriate command (git update-server-info) to make HTTP fetching and cloning work properly. This command is run when you push to this repository over SSH; then, other people can clone via something like

$ git clone http://10.145.10.50/git/test.git

Getting Git on a server

A bare repository is a repository that doesn't contain a working repository.
In order to clone your repository to create a new bare repository, you run the clone command with the --bare option. By convention, bare repository directories end in .git.

$ git clone --bare my_project my_project.git

This is roughly equivalent to something like

$ cp   -Rf    my_project/.git      my_project.git

Execute the following command in your remote bare repository folder:

git config --bool core.bare true

Configure Git server

Set up a "git" group. Members of this group will be able to push to the repo. Everyone else will be able to fetch only.

$ groupadd git

Then add your user to that group so that you can test. Change "ted" to your userid on the server.

$ gpasswd -a jerry git

Now we need to create the /var/www/html/git directory and set it up properly.

$ mkdir -p /var/www/html/git
$ cd /var/www/html
$ chown jerry:git git
$ chmod 775 git
$ chmod g+s git

Tell git that we want to do sharing with the git group. This should preserve the "git" group on all files along with the setgid bit on all directories. We'll double-check later just in case.

$ git config --global core.sharedRepository group

Now, you can create a new repository.

$ mkdir  /var/www/html/git/test

$ cd /var/www/html/git/test

$ git init --shared

$ mv .git ../test.git

$ rm -rf  test

To support the git protocol, you need to create a file git-export-daemon-ok under the git repository then execute git-update-server-info.

After the server is setup, you can test it via different protocols:

• git clone ssh://jerry@10.145.10.50:/var/www/html/git/test.git   test1
• git clone http://10.145.10.50/git/test.git  test2
• git clone git://10.145.10.50/test.git  test3

To allow developers can have write permission, you can setup SSH access in two ways:

1. The first is to set up accounts for everybody, which is straightforward but can be cumbersome. You may not want to run adduser and set temporary passwords for every user.
2. A second method is to create a single 'git' user on the machine, ask every user who is to have write access to send you an SSH public key, and append that key to the ~/.ssh/authorized_keys file of your new 'git' user. At that point, everyone will be able to access that machine via the 'git' user.  

Remember to change the permissions of the authorized_keys file and the folder / parent folders in which it is located:


chmod 700 /home/git/.ssh
chmod 600 /home/git/.ssh/authorized_keys


git clone ssh://git@10.145.10.50/var/www/html/git/test.git   test1

Generate user's public key

By default, a user’s SSH keys are stored in that user’s ~/.ssh directory.   If you don’t have these files (or you don’t even have a .ssh directory), you can create them by running a program called ssh-keygen. First it confirms where you want to save the key (.ssh/id_rsa), and then it asks twice for a passphrase, which you can leave empty if you don’t want to type a password when you use the key. The public key will be generated and stored in id_rsa.pub.

FAQ

1. "error: unable to write sha1 filename"
    Try the following:

• git repo-config core.sharedRepository tue
• chmod -R g+wX objects
• gpasswd -a jerry git

SubModules

Submodules allow you to keep a Git repository as a subdirectory of another Git repository. This lets you clone another repository into your project and keep your commits separate.

You can add extrenal projects as submodules with the git submodule add command:

  $ git submodule add ssh://git@10.145.10.50:/var/www/html/git/test_sub.git test_sub 

Now you have the test_sub project under a subdirectory named test_sub within your project.
Although test_sub is a subdirectory in your working directory, Git sees it as a submodule and doesn't track its contents when you're not in that directory. Instead, Git records it as a particular commit from that repository.

This is an important point with submodules: you record them as the exact commit they are at. You can't record a submodule as master or some other symbolic reference.