git服务器的建立——Git折腾小记

转自：http://blog.csdn.net/xsl1990/article/details/25486211

如果你能看到一些sshd相关的进程信息，则说明你已经有这个服务了，否则（或者你想更新的话），使用下面的命令安装openssh

1. sudo apt-get install openssh-server openssh-client

然后，安装git“服务器”

1. sudo apt-get install git-core

再然后，为自己配置身份信息，这样多个人提交代码的时候，就可以方便的查看是谁提交的，该如何联系ta了(如果该机器只做服务器，不做开发，本步骤应该可以省略)

1. git config --global user.name "yourname"
2. git config --global user.email "your@email.com"

以上步骤是每个git用户都需要的，接下来，作为“服务器”，为了更好的管理，我们需要进行一些必要的配置！包括环境的配置、管理工具的安装与配置等。

 

首先，我们最好为其配置一个专门的git用户并设置密码，专门对代码进行管理

1. sudo useradd -m git
2. sudo passwd git(change to yours)

 

说明：上述命令生成一个用户名与密码均为git的账户，也可以自己创建别的用户名跟密码，只要进行相关操作（比如clone）时指定用户名即可（本文章一律以git为例），-m 选项是让其在home目录下生成用户的主文件夹，我们的代码仓库会布置在这个主文件夹下。

 

然后，在新建的git用户主目录下创建一个文件夹作为git的仓库，并为这个仓库配备最基本的安防——权限控制

1. sudo mkdir /home/git/repositories # 最好使用repositories作为文件夹名称，这样可以简化后面的操作
2. sudo chown git:git /home/git/repositories
3. sudo chmod 755 /home/git/repositories

至此，一个简单（非常简单）的git服务器已经搭建好了，可以自己创建一个简单的工程测试一下。

为了方便后面的操作，我们先切换到git用户下

1. su git

在respositories下新建一个目录（仓库），并切换到这个目录

1. mkdir helloworld
2. cd helloworld

在此处初始化一个空的仓库（只能接受push/pull代码，不能本地commit）

1. git --bare init

好了，一个空的仓库建立好了，用另外一台安装了git的机器（比如你的开发机）测试一下，此处假设你上面所用的服务器IP为192.168.0.123

1. git clone git@192.168.0.123:/home/git/repositories/helloworld

然后在开发机上进行一些基本操作测试：为这个项目add一些文件，然后commit，然后push，如果除了要几次输入git用户的密码外，其他一切正常的话，那说明上面的安装与配置就已经成功了

 

在上面的测试过程中，是不是发现那个clone的路径好长，很容易错？几个步骤都需要输入git用户的密码（clone、push），是不是很烦，而且照这个节奏，每增加一个开发成员，就得告诉他git用户的密码，是不是既繁琐又不安全？所以，如果能clone的时候只要指定项目名称，clone/push/pull自动完成身份认证，并且最好能对不同的仓库给予不同用户不同的权限，那就好了！接下来介绍的工具与配置就可以搞定这一切，让git仓库的管理变得更简单，操作更方便！

 

首先，针对身份认证的问题，我们前面已经提到git的数据交换与操作都是基于ssh的，所以，我们的身份认证自然可以通过配置ssh来解决。ssh是通过密钥进行认证管理的，密钥包括一个公钥（交给服务器）和一个私钥（自己保留），每个公钥对应一个私钥，每个私钥也只对应一个公钥。。。。此处省略若干字。。。。，所以一个简单的解决自动身份认证的方式就是：每个需要访问代码仓库的人员，在自己的机器上通过ssh-keygen生成自己的公钥与私钥，将公钥提交给服务器，服务器管理员将改用户的公钥添加到服务器git用户的.ssh/authorized_keys文件中，可能用到的命令如下（Ubuntu终端/Windows下使用Git Bash）：

1. # 某开发机上
2. ssh-keygen #接下来一路回车就好了，在默认目录下生成默认密钥文件
3. cp ~/.ssh/id_rsa.pub /path/to/one/visiabl/fold/ #将隐藏文件夹下的公钥文件拷贝到一个可以文件夹下（如果接下来用scp提交，此步骤可省略）
4. # 将上面的公钥文件以某种方式提交给服务器
5. # 管理员在服务器下
6. # 将开发机提交上来的公钥文件，添加到/home/git/.ssh/authorized_keys文件中（每行一个）

这种方式可以在开发人员较少，管理的仓库较少的时候使用，因为简单，但是其权限控制比较单一（均可以read/update代码），而且如果人一多，要管理authorized_keys文件也是个头疼的事情，所以不是很推荐这种方式，建议采用后面介绍的工具。

然后，对于默认路径的问题，这个我真的只知道通过下面的管理工具来配置了。所以，接下来介绍一个git仓库的开源管理工具gitolite

gitolite安装

gitolite的官方介绍是这样的：Hosting git repositories -- Gitolite allows you to setup git hosting on a central server, with very fine-grained access control and many (many!) more powerful features.如其所述，它的主要功能就是对git仓库进行权限控制，并提供其他很多给力的方便管理的特性。其实我本来是要介绍gitosis的，但是自己在弄的时候，gitosis的配置出了一个非常诡异的问题，不管我怎么配置，甚至重新安装从零开始配置，总是再我更新它的配置文件后，之前的配置就不起作用了，折腾了我一天，最终发现了它的升级版——gitolite，所以决定采用它了。它们的本质都是上面介绍的ssh验证，只是它们提供更方便的管理方式，然后自动生成authorized_keys文件。这两个工具最有意思的一点就是，它们自身就是一个特殊的git版本库（gitolite-admin），他们的管理与配置都可以通过git的方式，分布式的进行修改，然后通过push的方式提交到服务器，服务器会通过所谓的钩子脚本自动更新权限控制文件。

下面介绍它的安装，它的官方主页上有详细的安装介绍，我这权当翻译跟经验分享。

首先，因为我的git仓库是在git用户下，所以，切换或者登陆到git用户下

1. su git

上面说过，gitolite本质就是根据你的配置，自动生成authorized_keys文件，所以它要求你的authorized_keys文件必须是空的，或者不存在，所以我们干脆删了它(请注意一定要切换到git用户，否则，误删除了其他用户下的authorized_keys文件导致服务器的其他功能受影响，那就悲剧了，这应该也算是为什么要专门弄一个git用户来管理的原因吧)

1. rm ~/.ssh/authorized_keys

然后，gitolite在初始化时需要通过某一用户的公钥文件指定一个超级管理员，gitolite安装成功后，只有这个超级管理员可以更新gitolite以更新各种权限控制（包括对其自身的更新权限控制），所以在初始化时需要指定该超级管理员账户的公钥文件（最好直接将其拷贝到git用户的主文件夹下）（下面的示例程序使用同一服务器上的另一常用管理员用户admin）

1. su admin
2. ssh-keygen
3. sudo cp ~/.ssh/id_rsa.pub /home/git/id_rsa.pub
4. su git

好~准备工作已经完成了，开始安装gitolite

1. cd ~ # 回到git主文件夹下
2. git clone git://github.com/sitaramc/gitolite # 获取gitolite的源码
3. mkdir -p $HOME/bin  #为gitolite的二进制文件生成创建目录
4. gitolite/install -to $HOME/bin  # 编译生成安装文件
5. $HOME/bin/gitolite setup -pk id_rsa.pub # 安装并初始化，指定id_rsa.pub公钥文件对应的用户为超级管理员

Bingo! gitolite安装完成！不过，你要用它来进行管理，那还需要一定的操作。上面提到，gitolite安装后本身是一个特殊的git版本库——gitolite-admin，分布式的进行修改，然后通过push的方式提交，其会通过钩子脚本执行权限更新。看一下上述步骤的最后一步你会发现，gitolite自动生成了两个版本库：gitolite-admin.git和testing.git，其中的gitol-admin.git就是那个特殊的神奇版本库。所以，接下来我们要做的，就是回到你刚刚指定的超级管理员账户的电脑跟账户下，clone出gitolite-admin这个特殊的git版本库（当前情况下，只有该超级管理员账户可以clone并更新gitolite-admin这个版本库），然后根据自己的需要对其进行配置（如添加更多的管理员账户、添加新的版本库并为不同的用户指定权限）

1. su admin # 回到指定的超级管理员账户
2. git clone git@192.168.0.123:gitolite-admin.git # clonegitolite-admin这个特殊的版本库

如果上面的步骤都成功了的话，应该可以查看到有一个gitolite-admin的文件夹，文件夹下有两个目录conf、keydir

如果你回到git用户，查看repositories目录（如果之前创建仓库时，创建的文件夹不是repositories，gitolite会自动创建这个文件夹，并将该文件夹作为默认访问时的默认路径），目录下就会多了gitolite-admin.git与testing.git两个版本库。

有没有发现，这次clone的时候，后面的路径变短了？密码也不用输了？腰不酸腿不痛了？对，你没猜错，这一切gitolite已经自动帮你搞定了：默认路径是/home/git/repositories，权限控制是只有当前的超级管理员用户可以访问gitolite-admin和testing两个版本库，你之前测试创建的版本库也已经无法访问，如果你尝试再次clone之前创建的测试版本库，应该就会提示如下错误信息：

1. # 假设你之前创建了helloworld版本库，现在使用git clone git@192.168.0.123:helloworld试图clone
2. FATAL: R any helloworld id_rsa DENIED by fallthru
3. (or you mis-spelled the reponame)
4. fatal: The remote end hung up unexppectedly

要继续访问之前创建的项目，需要将这个项目添加到gitolite的权限控制内，下面演示一下为当前的超级管理员用户指定之前创建的helloworld测试版本库的读写权限（可读可写），以此演示gitolite指定权限的一般流程：

1、将需要指定权限的用户的ssh公钥文件，存放在gitolite-admin版本库的keydir目录下（如果提交的都是id_rsa.pub，可以将其重命名为该用户的id或者名称，同时也推荐这样重命名，以明示哪个公钥文件是哪个用户的），因为我们初始化时，gitolite已经将该超级管理员的公钥文件自动拷进去了，所以省略此步骤

2、编辑conf目录下的gitolite.conf文件，添加helloworld版本库管理组，为超级管理员指定读写权限（RW+，具体的权限定义，参考gitolite官方文档）

1. repo helloworld
2. RW+  =   id_rsa

3、commit到本地

1. git commit -am 'add the helloworld repo and add RW+ to id_rsa'

4、push到git仓库

1. git push

如果push成功，当前超级管理员用户应该就可以成功clone helloworld版本库，并进行添加、删除、修改与push等操作了。

以上便是一个经典的管理过程，至于具体的权限控制、配置文件的格式、更多高级功能等，如果都介绍的话，这文章也太长了，所以读者还是参考官方文档（简单介绍，详细版本）吧，顺便学学英语。

 

一个基本的git服务器算基本完成了，当然如果要管理好，里面涉及到管理细节（不论是技术细节，还是管理策略）还有很多很多，我自己现在也只知道些皮毛，同时因为没有大项目的代码管理经验，都是我自己的小打小闹，所以就完全不敢出来献丑了，更多技术细节，大家可以查看官方文档，有机会我也许会再做点笔记分享，至于管理策略，推荐这个:A successful Git branching model ，这个也有”中文版“

 

git基本操作

其实这个已经有很多不错的资料了，所以也就懒得自己写了，罗列一点自己看过的资料好了：

我第一次接触git时，大哥推荐给我的资料：Git魔法，有pdf版本的，读者自己找找吧，如果没找到，也可以找我要，仅限学习~

git官网貌似一直就没上去过，看看这个中文翻译版本吧

一个不错的git简易指南

1.在服务器端创建专用帐号，所有用户通过此帐号访问git库，一般方便易记，选择git作为专用帐号名称。
$sudo adduser --system --shell /bin/bash --group git
添加git用户到ssh用户组中
$sudo adduser git ssh
为git用户设置口令，当整个git服务配置完成，最好取消git口令，只允许公匙认证。
$sudo passwd git
 2.到管理员主机将管理员公匙添加到服务器主机的.ssh/authorized_keys文件中，建立新的公匙认证，如：
$ssh-copy-id -i .ssh/<filename>.pub  git@server

3.服务器切换到git用户
$su git
安装gitolite
$sudo apt-get install gitolite
执行gitolite安装
$gl-setup  /<filename>.pub 以管理员公匙安装gitolite
安装过程会询问是否修改配置文件，一般会自动打开vi编辑.gitolite.rc文件。有些配置需要修改
$REPO_BASE="repositories"
用于设置Git服务器的根目录，缺省是git用户主目录下的repositories目录，可以使用绝对路径。所有git库都
部署在该路径下。
$REPO_UMASK=0007；#gets you 'rwxrwx--'
版本库创建使用的掩码。即新建立的版本库权限为‘rwxrwx’
$GL_BIG_CONFIG=0
如果授权文件非常复杂，更改此项配置为1，以免产生庞大的授权编译文件。
$GL_DILDREPOS=1
支持通配符版本库授权。
退出保存。
如果安装时没有配置，后续可以打开git用户跟目录下.gitolate.rc文件配置。

4.管理gitolite
当gitolite安装完成后，在服务器端创建了一个用于管理gitolite的库gitolite-admin.git

切换到管理员主机  $git clone git@server:gitolite-admin.git
$cd gitolite-admin
$ls -F
conf/   keydir/
$ls /conf
gitolite.conf
$ls keydir/
<filename>.pub
我们可以看出gitolite-admin目录下有两个目录conf/和keydir/.
keydir/<filename>.pub文件
目录keydir下初始时只有一个用户公匙，及管理员用户的公匙。
conf/gitolite.conf文件
该文件为授权文件，初始内容为
#gitolite conf
# please see conf/example.conf for details on syntax and features

repo gitolite-admin
    RW+                 = admin

repo testing
    RW+                 = @all

缺省授权文件中只设置了两个版本库的授权：

gitolite-admin

即本版本库（gitolite管理版本库）只有 admin 用户有读写和强制更新的权限。

testing

缺省设置的测试版本库，设置为任何人都可以读写以及强制更新。

5.增加新用户
只用将信用户的公匙添加到gitolite-admin版本库的Keydir目录下，即完成新用户的添加。如：
$ cp /path/to/dev1.pub keydir/
$ cp /path/to/dev2.pub keydir/
$ cp /path/to/jiangxin.pub keydir/
执行 git add 命令，将公钥添加入版本库。

$ git add keydir
$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       new file:   keydir/dev1.pub
#       new file:   keydir/dev2.pub
#       new file:   keydir/jiangxin.pub
#
$ git commit -m "add user: jiangxin, dev1, dev2"
[master bd81884] add user: jiangxin, dev1, dev2
 3 files changed, 3 insertions(+), 0 deletions(-)
 create mode 100644 keydir/dev1.pub
 create mode 100644 keydir/dev2.pub
 create mode 100644 keydir/jiangxin.pub

执行 git push，同步到服务器，才真正完成新用户的添加。

$ git push
Counting objects: 8, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (6/6), done.
Writing objects: 100% (6/6), 1.38 KiB, done.
Total 6 (delta 0), reused 0 (delta 0)
remote: Already on 'master'
remote:
remote:                 ***** WARNING *****
remote:         the following users (pubkey files in parens) do not appear in the config file:
remote: dev1(dev1.pub),dev2(dev2.pub),jiangxin(jiangxin.pub)

6.更改授权
新用户添加完毕，可能需要重新进行授权。更改授权的方法也非常简单，即修改 conf/gitolite.conf 配置文件，提交并 push。

管理员进入 gitolite-admin 本地克隆版本库中，编辑 conf/gitolite.conf 。

$ vi conf/gitolite.conf

授权指令比较复杂，我们先通过建立新用户组尝试一下更改授权文件。

考虑到之前我们增加了三个用户公钥之后，服务器端发出了用户尚未在授权文件中出现的警告。我们就在这个示例中解决这个问题。

例如我们在其中加入用户组 @team1，将新添加的用户 jiangxin, dev1, dev2 都归属到这个组中。

我们只需要在 conf/gitolite.conf 文件的文件头加入如下指令。用户之间用空格分隔。

@team1 = dev1 dev2 jiangxin
编辑结束，提交改动。

$ git add conf/gitolite.conf
$ git commit -q -m "new team @team1 auth for repo testing."

执行 git push ，同步到服务器，才真正完成授权文件的编辑

7.创建仓库示例
在conf/gitolite.conf中添加类似下面的内容进去
repo notes
  PW = <filename>
保存，提交，并推送到服务器
git add -u
git commit -m 'add new repo notes '
git push
推送的时候应该看到类似这样的信息

Counting objects: 7, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (4/4), 395 bytes, done.
Total 4 (delta 1), reused 0 (delta 0)
remote: Initialized empty Git repository in /home/git/repositories/notes.git/
To git@desktop:gitolite-admin
   6de90b8..52737aa  master -> master

注意remote开头的一行,它已经帮你创建了这个仓库

通配符创建仓库示例
通配符仓库事先不能确定名字,所以不会帮你创建,在你clone的时候才会创建

编辑conf/gitolite.conf文件在里面加入类似下面的内容

repo e2source/.+$
  C      =   <filename>
  RW+C   =   <filename>

注意C = username的一行必不可少,这里的C是指创建仓库的意思,下一行的RW+C中的C是指创建引用(branch,tag)的意思

保存后提交并推送到服务上去

git add -u
git commit -m 'add wildcard repo'
git push

注意看push时输出的信息,应该没有创建仓库的信息

这时filename克隆仓库的时候会自动创建

# as filename user
git clone git@server:e2source/enigam2-plugins.git

输出应该类似这样

Cloning into 'enigam2-plugins'...
Initialized empty Git repository in /home/git/repositories/e2source/enigam2-plugins.git/
warning: You appear to have cloned an empty repository.

如果你的输出报这样的错

FATAL: R any e2source/enigam2-plugins jenny DENIED by fallthru
(or you mis-spelled the reponame)
fatal: The remote end hung up unexpectedly

一般是没有C = username这一行,注意是只有C的一行