Gitolite easy deployment/management of git Server

For git, which is becoming more and more popular today, I believe that many developers are familiar with it. Its biggest convenience is the distributed development library, which allows developers who use git as the source code management library to submit code modifications locally without submitting them to a remote library, at the same time, when you need to collaborate with the team and synchronize code, there is only one more command. If you want to know the full picture of git, you can refer to "Pro git", which has a Chinese version. It seems that it has not been maintained recently, and Google it is needed.

The daily process of git users:

1. clone a copy from the remote git Server database to the local database (GIT clone ),

2. Perform local development and then submit modifications locally (files changed by git add; git commit). The cycle is infinite.

Steps 3, 3rd, and 4 are synchronized with the server. First, we need to take down the changes to the remote database and solve the problem of version merge locally (GIT pull)

4. Then, submit the merged local code library to the remote Library (GIT push). As planned by your team, it may be once a day.

5. In addition to synchronization with the server, the user can also be directly synchronized with other collaborators, such as the portrait icon on the left and in the middle.

The following describes how to use gitolite to manage git server for source code team collaboration. Readers of this article are advised to have Linux experience.

Gitolite Introduction

In fact, Every Git library simply requires-bare-shared to simply implement functions similar to the shared code library Server. In the GIT world, the code is freely shared and everyone plays a role, it is related to the permissions granted to the user by the Linux system. However, if the SSH authorized_keys method is used, the system directly uses the shell Method for git clone, A required permission management is missing-each user has full read and write permissions for all projects in a repository (the permission can be set through the Linux system, but it is still troublesome ), if multiple role permissions are involved in some large projects and the access path needs to be specified, authorized_keys can be directly managed, imagine if you want to manage the authorized_keys of a person greater than 1000?

Gitolite is a set of Perl scripts used to manage the authorized_keys file and implement fine-grained access control for the GIT server. Its official website is: Workshop. Today, gitolite not only exceeded its predecessor, gitosis, but also occupies a place in many large open-source communities. It manages the code repository ACL for the GIT server, these include the fedora community (which manages over 10000 warehouses), Kde community, Gentoo community, meego community, and kernel.org. Gitolite Implements user management and access control settings by managing a specified git repository. You only need to set the corresponding settings in the specified warehouse, and then push it to the server, gitolite will change the running policy accordingly.

Gitolite Installation Steps

The installation of gitolite is actually very simple. The Quick install provided on the official website is only four steps. You can refer to the instructions here. Gitolite also has multiple installation modes, such

1. Use the installation package for automatic installation; Apt-Get install/Yum install

2. Use the root account to manually install the global application, so that users on each server can open a code repository;

3. You can also manually install it under a specified normal user account.

The following installation uses the third method to minimize "contamination" of your Server Runtime Environment and update gitolite to the latest version at any time.

Installation environment

1. Suppose we have two machines, server and client;

2. The Administrator name for managing git server is sunny;

3. There is a common client user account Jacob

The following steps only show how-to of step-by-step. There are not many why values. For more information, see the official gitolite documentation, or Jiang Xin compiled the GIT authoritative guide.

In addition, gitolite installation depends on git. If you have not installed the GIT kit on your server, install it on your own.

For Deb: APT-Get install Git-core or apt-Get install git For RH: Yum install git

Procedure

1. First log on to the server and ask Root to create a new gituser account, because we want the source code repository to be placed under the normal account of the server:

[email protected]# adduser --system --shell /bin/bash --group gituser

2. Set a password for the user gituser. After the SSH public key is set up, the password can be disabled.

[email protected]# passwd gituser

3. The Administrator creates an SSH key pair

[email protected]$ ssh-keygen

If you do not want to affect some existing key pair of the local machine, the-F parameter is available.

[email protected]$ ssh-keygen -f sunny_key

4. Push the Administrator's public key to the remote server

[email protected]$ ssh-copy-id -i ~/.ssh/id_rsa.pub [email protected]

If the file is generated with the-F parameter, point to the correct file.

5. log on to the server as a gituser

[email protected]$ ssh [email protected]

6. Execute

[email protected]$ mv .ssh/authorized_keys sunny.pub

7. download the source code or install it automatically. It is recommended that you install the source code. If you are prompted to install the GIT version too old, you can download the old version gitolite, such as 2.1, or after 1.5.9, to download the old version, click here

[Email protected] $ git clone git: // github.com/sitaramc/gitolite # download source code [Email protected] $ gitolite/src/Gl-system-install # If git too old is prompted, download the old version of gitolite [Email protected] $ Gl-setup-Q ~ /Sunny. Pub

Note the following when executing Gl-setup:

To put Gl-setup in $ path, please confirm ~ /Bin is already placed in the PATH variable. If not, edit ~ /. Bashrc, add at the end

PATH=~/bin:$PATH

And execute the following command to take effect:

sh ~/.bashrc

The old version of GL-setup does not have the-Q Parameter. If you use the old version of gitolite (such as 1.5.9), you can directly assign the parameter.

[email protected]$ gl-setup ~/sunny.pub

8. Install the package management tool directly (skip this step if you do not need it)

[Email protected] $ sudo apt-Get install gitolite or [email protected] $ sudo Yum install gitolite

If sudo is not supported, log on to the root account and install sudo.

Gitolite management and permission settings

Gitolite management, including user management and code library management, is implemented by operating a database with a specified name: gitolite-Admin repository. Therefore, sunny, The gitolite administrator, needs to first capture the database locally, perform necessary configuration, and then push it to the remote server for the setting to take effect:

Capture gitolite-Admin repository to local

[email protected]$ git clone [email protected]:gitolite-admin [email protected]$ cd gitolite-admin

1. Add a user

Obtain the pubkey of the user (Jacob) to be added. If you do not know how to obtain the pubkey, ask Jacob to generate his own id_rsa.pub by referring to Step 3 above.

Sunny put the user Jacob's pubkey in the gitolite-admin/keydir directory and rename it Jacob. Pub

... # The premise is that Sunny obtains Jacob's pubkey through email, QQ, MSN, and other arbitrary methods and places it in the keydir directory. # In this example, Jacob gave pubkey id_rsa.pub. If jacob. Pub is given, skip this step. [Email protected]: ~ /Gitolite-admin/keydir $ MV id_rsa.pub Jacob. Pub

Execute add, commmit, and push.

[email protected]:~/gitolite-admin$ git add . [email protected]:~/gitolite-admin$ git commit -m "add jacob pubkey" [email protected]:~/gitolite-admin$ git push

At this time, Jacob has been added to gitolite. However, in addition to the testing library that comes with the system, Jacob cannot operate other libraries.

2. Add and set the code library

Now you want to create a code warehouse proj on the remote server. You still need to configure gitolite-Admin.

Edit gitolite-admin/CONF/gitolite. conf, and add:

Repo proj_a # The name of the newly added database is set here RW + = sunny # r is the read permission, W is the write permission, and + is the permission to force update a branch, delete a branch, and update a tag. RW = Jacob # The person who sets the RW permission

Execute add, commmit, and push.

[email protected]:~/gitolite-admin$ git add. [email protected]:~/gitolite-admin$ git commit -m "add a new repo" [email protected]:~/gitolite-admin$ git push

The format of gitolite. conf is actually quite complex (For details, refer to the official manual). Generally, there are enough open small teams like the following, for example:

@ Proj_a = sunny Jacob # @ proj_a is the group name. The group is represented by @ and can be referenced later. @ Proj_ B = sunny Taylor Jean # Use spaces to separate multiple users @ Admins = sunny @ QA = elapse Flora @ Engineers = sunny Jacob Taylor Jean @ Staff = @ admins @ QA @ engineers # The group can be referenced. Repo gitolite-Admin # This is the management warehouse of gitolite, and Sunny is the administrator who can perform operations on it. RW + = sunny Repo proj_a RW + = @ admins RW = @ proj_a elapse Repo proj_ B RW + = sunny RW = @ engineers Flora R refs/tags/= @ QA # The set here is the QA group. Only the read permission is granted to the files in the path starting with refs/tags /. Repo Testing RW + = @ stall

3. Check out common users

For example, Jacob wants to checkout the code library, modify it locally, and then merge it with the code of the remote database. These operations are purely git operations, and the team's daily development process is exactly like this. Refer to the Git workflow at the beginning of this article. The following are the checked-out methods for users in different situations.

Capture the remote database and modify it.

[Email protected]: ~ $ Git clone [email protected]: proj_a # The project is put in the proj_a directory by default. Or [Email protected]: ~ $ Git clone [email protected]: proj_a my_proj_a # The project is downloaded to the my_proj_a directory.

Jacob has a local ready-made project proj_a under development and is managed with git. Now he wants to share the project to proj_a

[Email protected]: ~ $ CD proj_a [Email protected]: ~ /Proj_a $ git push -- all [email protected]: proj_a # push to remote server

If you want to use an existing library (that is, merge projects) in the current directory, it is complicated. You need to replace the. Git/config file in an unconventional way.

4. delete a user

The Administrator locally deleted the user pubkey under the gitolite-admin/keydir directory, then executed the RM operation of git, then committed, and pushed.

[email protected]:~/gitolite-admin$ rm -f keydir/jacob.pub [email protected]:~/gitolite-admin$ git rm keydir/jacob.pub [email protected]:~/gitolite-admin$ git commit -m "delete a user" [email protected]:~/gitolite-admin$ git push

5. Delete the code library

Gitolite does not delete the repo code. to delete a repo, the administrator should take two steps:

Locally edit gitolite-admin/CONF/gitolite. conf, delete the relevant repo code, and then add, commit, push

[email protected]:~/gitolite-admin$ git add . [email protected]:~/gitolite-admin$ git commit -m "remove a repo" [email protected]:~/gitolite-admin$ git push

Use the gituser account or root account to enter the server and delete the related repo directories under gituser/Repositories

[Email protected]:/home/gituser/repositories $ Rm-RF proj_a.git # The Directory of the proj_a library, ending with. Git

6. modify the code library name

Renaming is also in two steps, which is the opposite of the order in which the deletion is executed,

First use the gituser account or root account to enter the server, CD repositories, and move

[email protected]:/home/gituser/repositories$ mv proj_a.git proj_b.git

Return to the client, modify CONF/gitolite. conf, change the old-name to new-name, add, commit, and push

7. List the databases with Permissions

Log on to the remote server using the account of Jacob, a common user,

[email protected]:ssh [email protected]

For example, return:

hello jacob, the gitolite version here is 1.5.4-2+squeeze1~bpo50+1 (Debian) the gitolite config gives you the following access: R W proj_a @R @W testing Connection to 192.168.0.101 closed.

The proj_a and testing listed above are the databases that user Jacob can operate on and have the R and W permissions.