技术控是否是都像我同样，我想试验在flask框架一些示例程序在nginx+uwsgi的生产环境下的效果，因而想到了用git实现自动部署，因而看到gitolite，因而研究gitolite的服务器配置以及钩子相关的实现方式，看到了网上不少人的回答都不另人满意，其实彻底能够有更简单的实现方式。有看官说了，你彻底能够写完以后用rsync手动部署啊，可是个人代码库是在本身的一个阿里云服务器上的，我会按期把代码推送到本身的GIT服务器上，我就是不想推送完后再运行一个部署的命令。linux

gitolite 工做原理

gitolite提供了便于部署git远程仓库的工具，它自己并不提供服务，服务仍旧依托ssh对外提供。若是没有这种工具的话，你以ssh的形式往远程的仓库里推送修改，则须要远程服务器中提供一个用户，若是用户多的话对远程服务器的安全隐患则较大。gitolite则是用一个专门的用户git来受理推送，并维护远程的库，你本地的用户只需将ssh公钥提交到远程服务器即可以受权推送。而且对于用户公钥的维护、相关配置文件的修改等均不须要登陆到远程服务器，在本地clone一个gitolite-admin的仓库，直接在本地修改，再推送到远程服务器上便可生效。nginx

gitolite是受到gitosis启发开发的，但如今功能上面已经全面超越了gitosis了。用过github的人可能比较熟悉这种用法，将本身本地的公钥提交到github以后，即可以用git clone git@github.com:username/reposity 的方式克隆一个远程库，本地修改提交到能够将相关内容再推送到远程。我不知道github采用的是什么工具实现的这种功能，但gitolite基本已经实现了这种功能。git

gitolite 安装与配置(远程服务器)

本文重点介绍gitolite实现Web的自动部署，gitolite的详细安装过程能够自行搜索，网上不少教程都写得不错。如下所指的远程服务器是指你要运行git仓库服务的服务器，本地是指要进行远程推送的主机，远程服务器上必须已经安装配置好ssh服务。github

安装gitolite

首先安装gitolite，我用的是archlinux，管方源里有，ubuntu的官方源里也有gitolite。web

添加并配置git用户

安装后查看一下系统有没有添加一个用户名为git的用户:shell

cat /etc/passwd |grep git

若是没有的话自行建立一个，并设置好此用户的根目录，这个目录即是用来存储git仓库的，若是已经有了这个用户的话，注意一下此用户的根目录的设置。flask

安装管理仓库及管理员帐号

安装管理仓库以及管理员帐号，首先将你要当管理员的帐号（能够是远程也能够是本地）用ssh-keygen生成一个ssh公钥(~/.ssh/id_rsa.pub)，将此公钥拷贝到服务器上，并命名为<yourusername>.pub，而后安装此公钥生成初始的管理仓库：ubuntu

su - git
gitolite setup -pk <yourusername>.pub

上面这一步安装完成后用ssh git@your_host_name info能够看到一些信息如：安全

hello <your_username>, this is git@<your_server> running gitolite3 v3.6.2 on git 2.3.3

  R W    gitolite-admin
  R W    testing

自动部署相关的配置

修改.gitolite.rc的相关配置(远程服务器)

进入到git用户的根目录用su - git切换到git目录，并对.gitolite.rc相关的配置进行修改，主要修改的地方有两处：ruby

找到.gitolite.rc中的这两行（并不在一块儿），去掉前面的注释：

LOCAL_CODE => "$rc{GL_ADMIN_BASE}/local",

repo-specific-hooks

克隆管理员仓库，并进行相关配置(本地)

下面是个人一个典型配置：

git clone git@<your_server>:gitolite-admin

如下全部的配置均是在本地进行的修改，最后提交到远程服务器端。

gitolite-admin下面有两个目录conf和keydir，第一个目录是用来存放配置文件，第二个目录用来存放用户的公钥，若是想添加用户的话能够将用户的公钥拷贝到此目录下并命名为<username>.pub的格式，而后git add、git commit、git push生效。

@devs = lxq gk
@admins = lxq
repo gitolite-admin
    RW+     =   @admins

repo testing
    RW+     =   @all

repo mysite
    option hook.post-receive= deploy
    RW+     =   @devs
    R       =   @all

repo lxq/.
    C       = lxq

第一、2行表示定义组，这些用户必须已经导入了公钥，能够为这个组设置权限。下面的几行均是为仓库设置权限，其中RW+是指可读写可强制更新。注意第4个repo的设置，指定lxq用户能够在lxq/目录下新建仓库，即C权限。这也是我最终抛弃gitosis选用gitolite的重要缘由，gitosis建仓库必须手动到远程服务器上去搞。

第3个仓库mysite的配置里有一条option hook.post-receive=deploy，gitolite扩展了git原有的钩子机制，表示这个仓库的post-receive钩子脚本为deploy，这样咱们每次向mysite这个仓库里推送完后即可以调用deploy这个脚本进行部署。

自动部署的相关准备(远程服务器)

肯定你要自动部署的目标目录，好比/srv/http/cgi-bin/mysite

cd /srv/http/cgi-bin
git clone git@your_host:mysite
sudo chown -R git:git mysite

建立deploy脚本(本地)

在gitolite-admin目录下建立特定的目录：

# on your workstation
cd /path/to/your/gitolite-admin-clone
mkdir -p local/hooks/repo-specific

而后在repo-specific下建立deploy脚本：

#!/bin/sh
cd /srv/http/cgi-bin/mysite
unset GIT_DIR
umask 022
git pull

如今配置已经基本完成，全部配置完成后，必定要记得git commit和git push，相关配置即会在服务器端生效。

自动部署！（本地操做、远程自动处理）

git clone git@yout_host:mysite

对mysite里的东西进行编辑以后，运行git commit、git push，远程便可自动将相关内容部署到/srv/http/cgi-bin/mysite下。