Build a git Server

In the "remote warehouse" section, we talked about the fact that the remote warehouse is no different from the local warehouse. It is purely for 7x24 boot and everyone's modifications are exchanged.

GitHub is a free remote repository hosting open-source code. However, for some commercial companies whose visual source code, such as life, do not want to disclose the source code, but do not want to pay the protection fee to GitHub, so they can only build a git server for use as a private repository.

To build a git server, you need to prepare a Linux machine. We strongly recommend using Ubuntu or Debian. In this way, you can install it using several simple apt commands.

Assume that you have the sudo permission for the user account, and the installation will officially start below.

Step 1: Install git:

$ sudo apt-get install git

Step 2: Create a git user to run the GIT service:

$ sudo adduser git

Step 3: Create a certificate to log on:

Collect the public keys of all users that need to log on, that is, their own id_rsa.pub file, and import all the public keys/Home/git/. Ssh/authorized_keysFile, one line.

Step 4: Initialize the GIT Repository:

Select a directory as the GIT repository. Assume It is/srv/sample. Git and enter the command in the/srv directory:

$ sudo git init --bare sample.git

Git creates a bare repository without a work zone. Because the GIT repository on the server is purely for sharing, users are not allowed to directly log on to the server to change the work zone, and the GIT repository on the server usually uses. git end. Then, change the owner to git:

$ sudo chown -R git:git sample.git

Step 5: Disable shell Logon:

For security reasons, the GIT user created in step 2 is not allowed to log on to the shell, which can be completed by editing the/etc/passwd file. Find a line similar to the following:

git:x:1001:1001:,,,:/home/git:/bin/bash

Changed:

git:x:1001:1001:,,,:/home/git:/usr/bin/git-shell

In this way, git users can normally use git through SSH, but cannot log on to the shell, because the git-shell that we specify for git users will automatically exit upon every login.

Step 6: clone a remote Repository:

Now, you can useGit cloneClone the remote repository by running the following command on your computer:

$ git clone [email protected]:/srv/sample.gitCloning into ‘sample‘...warning: You appear to have cloned an empty repository.

The rest of the push is simple.

Manage public keys

If the team is small, collect everyone's public keys and place them on the server/Home/git/. Ssh/authorized_keysFile is feasible. If the team has hundreds of people, they won't be able to do that. In this case, you can use gitosis to manage the public key.

Here we will not introduce how to use gitosis. The team of hundreds of employees is basically in the top 500. I believe it is not a problem to find a high-level Linux administrator.

Manage Permissions

There are many companies that don't only regard the source code as life, but also regard employees as thieves. They will set up a complete set of permission control in the version control system, whether each person has the read/write permission is accurate to each branch or even each directory. Because git is developed for Linux source code hosting, GIT also inherits the spirit of the open source community and does not support permission control. However, because git supports hooks, you can write a series of scripts on the server to control the submission and other operations to achieve permission control. Gitolite is the tool.

Here we will not introduce gitolite, and do not waste the limited life in the permission struggle.

Summary

It is very easy to build a git server, usually within 10 minutes;

To facilitate public key management, use gitosis;

Attackers can use gitolite to control permissions as easily as SVN does.