How to build your own Git Server

How to build your own Git Server
GuideNow we will learn how to build a git server, how to write custom Git hooks to trigger corresponding actions (such as notifications) in a specific event, or publish your code to a site.

Till now, we mainly discuss how to interact with Git as a user. In this article, I will discuss Git management and design a flexible Git framework. You may think this sounds like a euphemism for "Advanced Git technology" or "reading only with fanatic fans, however, the fact is that every task here does not require deep knowledge or other special training, so you can basically understand how Git works. You may need a little bit of knowledge about Linux.

Shared Git Server

Creating your own shared Git server is surprisingly simple, and in many cases, the trouble is worth it. Not only does it ensure that you have the permission to view your code, but it also opens a door for Git's use through extension, for example, personal Git hooks, unrestricted data storage, and continuous integration and distribution (CI & CD ).

If you know how to use Git and SSH, you already know how to create a Git server. Git is designed to allow you to build half of the servers when creating or cloning a repository. Then, allow SSH access to the repository, and anyone with access permissions can use your repository as the basis for cloning the new repository.

However, this is a small point-to-point environment (ad-hoc ). Based on some schemes, you can create Git servers with the same features and have better scalability.

First of all: confirm that your users, current users and subsequent users must consider. If you are the only user, there is no need for any changes. However, if you try to invite other code contributors, you should allow a dedicated sharing system user to your developers.

Suppose you have an available server (if not, this is not a problem, Git will help solve it, and raspberry 3 of CentOS is a good start ), then, the first step is to allow only SSH logon Using SSH key authentication. This is much safer than using a password to log on, because it can be free from brute force cracking, or you can disable a user by directly deleting the User Key.

Once you have enabled SSH key authentication, create a gituser. This is a public user for all authorized users:

        $su-c'addusergituser'

Switch to the newly created gituser and create ~ /. Ssh framework, and set the appropriate permissions. This is very important. If the permission is set too open, it will make your own SSH protection meaningless.

        $su-gituser        $mkdir.ssh&&chmod700.ssh        $touch.ssh/authorized_keys        $chmod600.ssh/authorized_keys

The authorized_keys file contains the SSH public keys of all your developers. You are open to allow them to work on your Git project. They must create their own SSH key pair and then give you their public key. Copy the public key to the authorized_keys file under the gituser. For example, for a developer named Bob, run the following command:

        $cat~/path/to/id_rsa.bob.pub>>/home/gituser/.ssh/authorized_keys

As long as the developer Bob has a private key and delivers the corresponding public key to you, Bob can use the gituser user to access the server.

However, you do not want your developers to use the server, even if they only access the server as gituser. You just want to give them the permission to access the Git repository. For this special reason, Git provides a restricted shell, specifically git-shell. Run the following command as root to add git-shell to your system and set it to the default shell of gituser.

        #grepgit-shell/etc/shells||su-c"echo`whichgit-shell`>>/etc/shells"        #su-c'usermod-sgit-shellgituser'

Currently, gituser users can only use SSH to push or pull Git repositories, and cannot use any shell that can be logged on. You should add yourself to the same group as gituser. In our sample server, the group name is also gituser.

For example:

        #usermod-a-Ggituserseth

The only remaining step is to create a Git repository. No one can directly interact with Git on the server (that is, you cannot SSH to the server and then directly operate on the repository), so create an empty repository. If you want to use this repository on the server to complete the work, you can clone it from its location and then work in your home directory.

Strictly speaking, you do not have to create this empty repository; it works just like a normal repository. However, an empty warehouse does not have a working tree (that is, no branch is displayed using checkout ). This is important because remote users are not allowed to push to a valid branch (if you are working in the dev branch and then someone suddenly pushes some changes to your branch, how do you feel ?). Because an empty warehouse does not have a valid branch, this is not a problem.

You can place this repository wherever you want, as long as you want to grant permissions to users and user groups so that they can work in the repository. Do not save the directory to the home Directory of a user, for example, because there are strict permission restrictions. Save it to a common shared address, such as/opt or/usr/local/share.

Create an empty repository as root:

 #gitinit--bare/opt/jupiter.git        #chown-Rgituser:gituser/opt/jupiter.git #chmod-R770/opt/jupiter.git

Now, any user who is authenticated as gituser or in the gituser group can read or write data from the jupiter. git library. On the local machine, try the following operations:

 $gitclonegituser@example.com:/opt/jupiter.gitjupiter.clone Cloninginto'jupiter.clone'... Warning:youappeartohaveclonedanemptyrepository.

Keep in mind: developers must add their SSH public keys to the authorized_keys file under the gituser user, or if they have users on the server (if you give them the user ), then their users must belong to the gituser group.

Git hook

One of the most amazing ways to run your own Git server is to use the Git hook. The Git hosting service sometimes provides a hook interface, but it does not give you a real Git hook to allow you to access the file system. A Git hook is a script that runs at certain points in a Git process. A hook can run after a repository receives a commit or a commit, or when a push is to be received, or after a push.

This is a simple system: any script placed in the. git/hooks directory can run at the designed time using the standard naming system. Whether a script should be run depends on its name, pre-push script runs before push, post-receive script runs after receiving commit, and so on. This can be viewed more or less by name.

Scripts can be written in any language. If you have a scripting language that can be executed on your system, such as outputting 'Hello world', you can write Git hook scripts in this language. Git includes some examples by default, but is not enabled.

Do you want to give it a try? This is simple. If you do not have a ready-made Git repository, first create a Git Repository:

 $mkdirjupiter $cdjupiter $gitinit.

Then write a "hello world" Git hook. Because I use tsch to support old systems, I still use it as my scripting language. You can use your preferred language (Bash, Python, Ruby, Perl, rust, Swift, Go ):

 $echo"#/!/bin/tcsh">.git/hooks/post-commit $echo"echo'POST-COMMITSCRIPTTRIGGERED'">>~/jupiter/.git/hooks/post-commit $chmod+x~/jupiter/.git/hooks/post-commit

Now test its output:

 $echo"helloworld">foo.txt $gitaddfoo.txt $gitcommit-m'firstcommit' !POST-COMMITSCRIPTTRIGGERED [master(root-commit)c8678e0]firstcommit 1filechanged,1insertion(+) createmode100644foo.txt

Now you have implemented: Your first functional Git hook.

Famous push-to-web hook

The most popular usage of Git Hooks is to automatically push the changed code to a directory of a product-level Web server in use. This is a good way to get rid of FTP, and retain full version control for the products in use, integrate and automate the release of content.

If the operation is correct, the website publishing work will be completed as well as before, and to some extent, very accurate. Git is really great. I don't know who first came up with this idea, but I first heard of it from Emacs and Git experts, IBM's Bill von Hagen. His article contains an authoritative introduction to this process: Git has changed the game rules for Distributed Web development.

Git variable

Each Git Hook has a series of different variables that correspond to different Git actions that trigger the hook. If you do not need these variables, it depends on the program you write. If you only need a general email notification when someone pushes the code, you don't need anything special or even need to write additional scripts, because there are already ready-made sample scripts suitable for you. If you want to view the commit information and the author of the commit in the email, your script will become more troublesome.

Git hooks are not directly executed by users, so you need to find out how to collect important information that may be obfuscated. In fact, Git hook scripts are similar to other scripts, such as BASH, Python, C ++, and so on. They read parameters from standard input. The difference is that we will not provide this input for it, so you need to know the possible input parameters when using it.

Before writing a Git hook, let's take a look at some examples provided by Git in the. git/hooks directory under your project directory. For example, the comments section in this pre-push.sample file illustrates the following:

#$1 -- Name of the remote repository to be pushed #$2 -- URL of the remote repository to be pushed # If no remote repository is named during push, the two parameters will be the same. # Submitted information: Send the following columns to the standard input in rows # <localref> <localsha1> <remoteref> <remotesha1>

Not all examples are so clear, and the documentation on getting variables from hooks is still lacking (unless you read the Git source code ). However, if you have any questions, you can learn from other online user attempts, or you just need to write some basic scripts, such as echo $1, $2, and $3.

Branch Detection example

I found that there is a common requirement for a production environment, that is, a hook that triggers an event only after a specific branch is modified. The following is an example of how to track branches.

First, the Git hook itself is not under version control. Git does not track its own hooks, because it is part of Git, not part of your repository. Therefore, the Git Hook can monitor the commit record and push record of an empty repository on your Git server, rather than part of your local repository.

Let's write a post-receive (that is, triggered after the commit is accepted) Hook. The first step is to determine the branch name:

 #!/bin/tcsh foreacharg($<) setargv=($arg) setrefname=$1 end

This for loop is used to read the first parameter $1, then overwrite it with the second parameter $2, and then use the third parameter $3. There is a better method in Bash. Use the read command and put the value in the array. However, here is tcsh, and the sequence of variables can be predicted. Therefore, this method is also feasible.

When we have the refname record of the commit record, we can use Git to find the branch name for people to see:

 setbranch=`gitrev-parse--symbolic--abbrev-ref$refname` echo$branch#DEBUG

Then compare the branch name with the branch name keyword of the event we want to trigger:

 if("$branch"=="master")then echo"Branchdetected:master" git/ --work-tree=/path/to/where/you/want/to/copy/stuff/to/ checkout-f$branch||echo"masterfail" elseif("$branch"=="dev")then echo"Branchdetected:dev" Git/ --work-tree=/path/to/where/you/want/to/copy/stuff/to/ checkout-f$branch||echo"devfail" else echo"Yourpushwassuccessful." echo"Privatebranchdetected.Noactiontriggered." endif

Assign the executable permission to the script:

        $chmod+x~/jupiter/.git/hooks/post-receive

Now, when a user submits the code to the master branch of the server, the code will be copied to the directory of a production environment, and the Code submitted to the dev branch will be copied to another place, other branches will not trigger these operations.

At the same time, it is easy to create a pre-commit script. For example, you can determine whether a user pushes code on the branch where they are not supposed to push, or parse the commit information.

Git hooks can also become complex, and they become hard to understand because of different abstract layers of Git workflows, but they are indeed a powerful system, this allows you to perform operations on all behaviors on your Git infrastructure. If you are a serious Git user or a full-time Git administrator, Git hooks are worth learning. Only when you are familiar with this process can you really master it.

In the next and last articles in our series, we will learn how to use Git to manage non-text binary data, such as audio and images.

From: http:// OS .51cto.com/art/201609/517927.htm

Address: http://www.linuxprobe.com/found-git-server.html