Gitolite-based Git service setup

If you do not want to work with others, git does not need to set up servers at all. git can directly use the path of the local version library to perform operations between git versions. However, if you want to share the version library with others for collaborative development, you need to be able to operate the git library through the network protocol. Git supports a wide range of protocols and many Server SETUP options. Different solutions have their own public advantages and disadvantages. This article uses gitolite as an example to build an efficient git server for multi-person collaboration.

Environment:

Git client test.cmmobi.com (172.16.5.202). The git server is git.cmmobi.com (172.16.5.200 ). Configure the/etc/hosts file for mutual parsing.

Cat/etc/hosts

172.16.5.202 test.cmmobi.com
172.16.5.200 git.cmmobi.com

Client configuration (configuration on test.cmmobi.com)
Create a user and generate a key pair. To facilitate the test, you can directly use the root user instead of creating another user.
Cd/root
Mkdir. ssh
Ssh-keygen-f ~ /. Ssh/admin
Upload the generated public key to the/tmp directory of the git server for backup
Scp ~ /. Ssh/admin. pub root@git.cmmobi.com:/tmp
Create a configuration file for accessing the git Service
Cat ~ /. Ssh/config
Host gitolite # git server alias
User git # users who manage gitolite on the server
Hostname git.cmmobi.com # Host Name of the git Server
Port 22 # port number used to access the git Server
Identityfile ~ /. Ssh/admin # public key file used to access the git Server
Chmod 600 ~ /. Ssh/config

Server configuration (git.cmmobi.com)
Service requirements:
1. Any unix System
2. shell Environment
3. The git version is 1.6.6 or later.
4. The perl version is 5.8.8 or later.
5. openssh version 5.0 or later
Installation:
1. log on to the server as the root user and create a git user to manage the git service.
Useradd git
Echo "git" | passwd git -- stdin
2. Switch to the git user and make sure that ~ The/. ssh/authorized_keys file is null or does not exist.
3. Perform the installation:
Git clone git: // github.com/sitaramc/gitolite # download gitolite Software
Mkdir-p $ HOME/bin
Gitolite/install-to $ HOME/bin # install gitolite
Export PATH = $ PATH: $ HOME/bin
Echo "PATH = $ PATH: $ HOME/bin">. bashrc
Gitolite setup-pk/tmp/admin. pub # configure the root user of the client as the git Administrator
If the following error is reported when you execute gitolite/install-to $ HOME/bin:
Can't locate Time/HiRes. pm in @ INC (@ INC contains: /home/git/gitolite/src/lib/usr/local/lib64/perl5/usr/local/share/perl5/usr/lib64/perl5/vendor_perl/usr/share/perl5 /vendor_perl/usr/lib64/perl5/usr/share/perl5 .) at/home/git/gitolite/src/lib/Gitolite/Common. pm line 74.
BEGIN failed -- compilation aborted at/home/git/gitolite/src/lib/Gitolite/Common. pm line 74.
Compilation failed in require at./install line 15.
BEGIN failed -- compilation aborted at./install line 15.
Need to install perl-Time_HiRes:
Yum install-y perl-Time-HiRes

After the installation is complete, we can see a repositories directory under $ HOME, which contains two warehouses: gitolite-admin and testing, where gitolite-admin is the management warehouse.
Clone the gitolite-admin library from the client using the root user
Git clone gitolite: gitolite-admin
Go to the gitolite-admin repository, and you will see two directories, keydir and conf. The keydir directory is used to manage users. In this example, the default file is admin. pub is the public key file that we previously generated to manage users. Next we will add another user breezey:
Useradd breezey
Echo "breezey" | passwd breezey -- stdin
Su-breezey
Mkdir. ssh
Ssh-keygen-f. ssh/breezey
Vim. ssh/config
Host gitolite
User git
Hostname git.cmmobi.com
Port 22
Identityfile ~ /. Ssh/breezey
Su-root # switch back to Manage Users
Cp/home/breezey/. ssh/breezey. pub/root/gitolite-amdin/keydir
Cd/root/gitolite-admin
Git add keydir
Git status
Git config-global user. email "breezey@cmmobi.com"
Git config -- global user. name "breezey"
Git commit-a "add user: breezey"
Git push
Su-breezey # Switch to the breezey user
Git clone gitolite: testing # clone the testing repository.
We can go to the testing library to create a test file and submit it:
Cd testing
Echo "Hello World"> welcome.txt
Git add *
Git commit-m "a new file: welcome.txt"
Git push
When we commit and execute git push for the first time, the following error occurs:
No refs in common and none specified; doing nothing.
Perhaps you shoshould specify a branch such as 'master '.
Fatal: The remote end hung up unexpectedly
Error: failed to push some refs to 'gitolite: test1'
The cause of this problem is that git cannot find the version you want to submit. You can use the following command:
Git push origin master

Gitolite authorization details
As mentioned above, there are two directories in the gitolite-admin management warehouse, the keydir directory is the directory for managing users, and the other conf directory is called gitolite. conf configuration file, which is the file used to manage the repository and user authorization.
Let's take a look at an example of this configuration file:
1 @ admin = breezey chenliang
2 repo gitolite-admin
3 RW + = breezey
4 repo ossxp/. +
5 C = @ admin
6 RW = @ all
7 repo testing
8 RW + = @ admin
9 RW master = junio
10 RW + pu = junio
11 RW cogito $ = pasky
12 RW bw/= linus
13-= somebody
14 RW tmp/= @ all
15 RW refs/tags/v [0-9] = junio
Let's give a brief description of the example file to help you have a basic understanding of the authorization file:
Row 1st defines an admin group, which contains two users: breezey chenliang
Line 2-3 defines a version library gitolite-admin and specifies that the breezey user has the read (R), write (W), and force Update (+) permissions for the gitolite-admin repository.
Row 4th defines a set of version libraries through regular expressions, that is, all version libraries under the ossxp directory.
Users who define the admin group in row 5th can create version libraries in the ossxp directory.
Row 6th defines that all users have read and write permissions on the version libraries under the ossxp directory, but cannot force update
Row 7th defines a version library testing.
Row 8th defines that the admin group has the read, write, reset, add, and delete permissions on all the branches and tags of the testing database.
Row 9th defines that the junio user has the read and write permissions on the master branch, and also includes all the branches starting with the master.
Row 3 defines the permissions of junio users to read, write, reset, add, and delete pu branches, and all branches starting with pu.
Row 3 defines the read and write permissions of the pasky user on the cogito branch. Only this branch is used for exact match.
Row 3 defines the read and write permissions of the linus user on bw /.
Line 3 defines the somebody user's permission to write to the testing repository.
Row 3 defines the read and write permissions of all users on tmp /.
Row 3 defines that junio can read and write arbitrary tags, including tags starting with v and a number.

Group definition:
@ Admin = breezey chenliang
@ User = @ admin @ staff user1
Definition of version Library:
Repo ossxp/. + # match all version libraries in the ossxp directory
Repo myrepo. $ # match the version library ending with myrepo.
Repo sandbox/test1 # create the test1 database under sandbox
Authorization Keyword:
C:
C Indicates creation. It can only be used when vertices are authorized. Used to specify who can create a version library that matches the wildcard.
R, RW, RW +:
R is read-only, RW is read/write, RW + is read/write and forced push
RWD, RW + D:
This authorization instruction can be used only when regular references (branch and tag defined by regular expressions) are defined in the authorization instruction. Where D indicates that it is allowed to delete references matching regular references (branch or tag)
RWCD, RW + CD:
This authorization instruction can be used only when regular references (branch and tag defined by regular expressions) are defined in the authorization instruction. Here, C indicates that you can create a reference (branch or tag) that matches the regular reference. D indicates that you can delete a reference that matches the regular reference (branch or tag)
-:
Minus sign (-) is a disabled command that only takes effect for write operations and does not affect user read operations.

Git details: click here
Git: click here

Recommended reading:

Fedora downloads Git through Http Proxy

Install Git on Ubuntu Server

Create a Git repository on the server (Ubuntu)

Git simple tutorial in Linux (taking Android as an example)

Git authoritative guide PDF