Git详解之四 服务器上的Git（第一部分）

       到目前为止，你应该已经学会了使用 Git 来完成平常工做。然而，若是想与他人合做，还须要一个远程的 Git 仓库。尽管技术上能够从我的的仓库里推送和拉取修改内容，但咱们不鼓励这样作，由于一不留心就很容易弄混其余人的进度。另外，你也必定但愿合做者们即便在 本身不开机的时候也能从仓库获取数据 — 拥有一个更稳定的公共仓库十分有用。所以，更好的合做方式是创建一个你们均可以访问的共享仓库，从那里推送和拉取数据。咱们将把这个仓库称为 “Git 服务器”；代理一个 Git 仓库只须要花费不多的资源，几乎从不须要整个服务器来支持它的运行。

架设一台 Git 服务器并不难。第一步是选择与服务器通信的协议。本章第一节将介绍可用的协议以及各自优缺点。下面一节将介绍一些针对各个协议典型的设置以及如何在服务器 上实施。最后，若是你不介意在他人服务器上保存你的代码，又想免去本身架设和维护服务器的麻烦，倒能够试试咱们介绍的几个仓库托管服务。

若是你对架设本身的服务器没兴趣，能够跳到本章最后一节去看看如何申请一个代码托管服务的帐户而后继续下一章，咱们会在那里讨论分布式源码控制环境的林林总总。

远程仓库一般只是一个_裸仓库（bare repository）_ — 即一个没有当前工做目录的仓库。由于该仓库只是一个合做媒介，因此不须要从硬盘上取出最新版本的快照；仓库里存放的仅仅是 Git 的数据。简单地说，裸仓库就是你工做目录中.git 子目录内的内容。

4.1  协议

       Git 可使用四种主要的协议来传输数据：本地传输，SSH 协议，Git 协议和 HTTP 协议。下面分别介绍一下哪些情形应该使用（或避免使用）这些协议。值得注意的是，除了 HTTP 协议外，其余全部协议都要求在服务器端安装并运行 Git。

本地协议

       最基本的就是_本地协议（Local protocol）_，所谓的远程仓库在该协议中的表示，就是硬盘上的另外一个目录。这常见于团队每个成员都对一个共享的文件系统（例如 NFS）拥有访问权，或者比较少见的多人共用同一台电脑的状况。后面一种状况并不安全，由于全部代码仓库实例都储存在同一台电脑里，增长了灾难性数据损失 的可能性。若是你使用一个共享的文件系统，就能够在一个本地文件系统中克隆仓库，推送和获取。克隆的时候只须要将远程仓库的路径做为 URL 使用，好比下面这样：

$ git clone /opt/git/project.git

或者这样：

$ git clone file:///opt/git/project.git

        若是在 URL 开头明确使用 file:// ，那么 Git 会以一种略微不一样的方式运行。若是你只给出路径，Git 会尝试使用硬连接或直接复制它所须要的文件。若是使用了file:// ，Git 会调用它平时经过网络来传输数据的工序，而这种方式的效率相对较低。使用 file:// 前缀的主要缘由是当你须要一个不包含无关引用或对象的干净仓库副本的时候 — 通常指从其余版本控制系统导入的，或相似情形（参见第 9 章的维护任务）。咱们这里仅仅使用普通路径，这样更快。

要添加一个本地仓库做为现有 Git 项目的远程仓库，能够这样作：

$ git remote add local_proj /opt/git/project.git

而后就能够像在网络上同样向这个远程仓库推送和获取数据了。

优势

      基于文件仓库的优势在于它的简单，同时保留了现存文件的权限和网络访问权限。若是你的团队已经有一个全体共享的文件系统，创建仓库就十分容易了。你 只需把一份裸仓库的副本放在你们都能访问的地方，而后像对其余共享目录同样设置读写权限就能够了。咱们将在下一节“在服务器上部署 Git ”中讨论如何导出一个裸仓库的副本。

        这也是从别人工做目录中获取工做成果的快捷方法。假如你和你的同事在一个项目中合做，他们想让你检出一些东西的时候，运行相似 git pull /home/john/project 一般会比他们推送到服务器，而你再从服务器获取简单得多。

缺点

       这种方法的缺点是，与基本的网络链接访问相比，难以控制从不一样位置来的访问权限。若是你想从家里的笔记本电脑上推送，就要先挂载远程硬盘，这和基于网络链接的访问相比更加困难和缓慢。

另外一个很重要的问题是该方法不必定就是最快的，尤为是对于共享挂载的文件系统。本地仓库只有在你对数据访问速度快的时候才快。在同一个服务器上，若是两者同时容许 Git 访问本地硬盘，经过 NFS 访问仓库一般会比 SSH 慢。

SSH 协议

        Git 使用的传输协议中最多见的可能就是 SSH 了。这是由于大多数环境已经支持经过 SSH 对服务器的访问 — 即使尚未，架设起来也很容易。SSH 也是惟一一个同时支持读写操做的网络协议。另外两个网络协议（HTTP 和 Git）一般都是只读的，因此虽然两者对大多数人均可用，但执行写操做时仍是须要 SSH。SSH 同时也是一个验证受权的网络协议；而由于其广泛性，通常架设和使用都很容易。

经过 SSH 克隆一个 Git 仓库，你能够像下面这样给出 ssh:// 的 URL：

$ git clone ssh://user@server:project.git

或者不指明某个协议 — 这时 Git 会默认使用 SSH ：

$ git clone user@server:project.git

若是不指明用户，Git 会默认使用当前登陆的用户名链接服务器。

优势

       使用 SSH 的好处有不少。首先，若是你想拥有对网络仓库的写权限，基本上不可能不使用 SSH。其次，SSH 架设相对比较简单 — SSH 守护进程很常见，不少网络管理员都有一些使用经验，并且不少操做系统都自带了它或者相关的管理工具。再次，经过 SSH 进行访问是安全的 — 全部数据传输都是加密和受权的。最后，和 Git 及本地协议同样，SSH 也很高效，会在传输以前尽量压缩数据。

缺点

       SSH 的限制在于你不能经过它实现仓库的匿名访问。即便仅为读取数据，人们也必须在能经过 SSH 访问主机的前提下才能访问仓库，这使得 SSH 不利于开源的项目。若是你仅仅在公司网络里使用，SSH 多是你惟一须要使用的协议。若是想容许对项目的匿名只读访问，那么除了为本身推送而架设 SSH 协议以外，还须要支持其余协议以便他人访问读取。

Git 协议

      接下来是 Git 协议。这是一个包含在 Git 软件包中的特殊守护进程； 它会监听一个提供相似于 SSH 服务的特定端口（9418），而无需任何受权。打算支持 Git 协议的仓库，须要先建立git-export-daemon-ok 文件 — 它是协议进程提供仓库服务的必要条件 — 但除此以外该服务没有什么安全措施。要么全部人都能克隆 Git 仓库，要么谁也不能。这也意味着该协议一般不能用来进行推送。你能够容许推送操做；然而因为没有受权机制，一旦容许该操做，网络上任何一个知道项目 URL 的人将都有推送权限。不用说，这是十分罕见的状况。

优势

      Git 协议是现存最快的传输协议。若是你在提供一个有很大访问量的公共项目，或者一个不须要对读操做进行受权的庞大项目，架设一个 Git 守护进程来供应仓库是个不错的选择。它使用与 SSH 协议相同的数据传输机制，但省去了加密和受权的开销。

缺点

       Git 协议消极的一面是缺乏受权机制。用 Git 协议做为访问项目的惟一方法一般是不可取的。通常的作法是，同时提供 SSH 接口，让几个开发者拥有推送（写）权限，其余人经过git:// 拥有只读权限。Git 协议可能也是最难架设的协议。它要求有单独的守护进程，须要定制 — 咱们将在本章的 “Gitosis” 一节详细介绍它的架设 — 须要设定xinetd 或相似的程序，而这些工做就没那么轻松了。该协议还要求防火墙开放 9418 端口，而企业级防火墙通常不容许对这个非标准端口的访问。大型企业级防火墙一般会封锁这个少见的端口。

HTTP/S 协议

       最后还有 HTTP 协议。HTTP 或 HTTPS 协议的优美之处在于架设的简便性。基本上，只须要把 Git 的裸仓库文件放在 HTTP 的根目录下，配置一个特定的post-update 挂钩（hook）就能够搞定（Git 挂钩的细节见第 7 章）。此后，每一个能访问 Git 仓库所在服务器上 web 服务的人均可以进行克隆操做。下面的操做能够容许经过 HTTP 对仓库进行读取：

$ cd /var/www/htdocs/ 
$ git clone --bare /path/to/git_project gitproject.git 
$ cd gitproject.git 
$ mv hooks/post-update.sampl

这样就能够了。Git 附带的 post-update 挂钩会默认运行合适的命令（git update-server-info）来确保经过 HTTP 的获取和克隆正常工做。这条命令在你用 SSH 向仓库推送内容时运行；以后，其余人就能够用下面的命令来克隆仓库：

$ git clone http://example.com/gitproject.git

在本例中，咱们使用了 Apache 设定中经常使用的 /var/www/htdocs 路径，不过你可使用任何静态 web 服务 — 把裸仓库放在它的目录里就行。 Git 的数据是以最基本的静态文件的形式提供的（关于如何提供文件的详情见第 9 章）。

经过 HTTP 进行推送操做也是可能的，不过这种作法不太常见，而且牵扯到复杂的 WebDAV 设定。因为不多用到，本书将略过对该内容的讨论。若是对 HTTP 推送协议感兴趣，不妨打开这个地址看一下操做方法：http://www.kernel.org/pub/software/scm/git/docs/howto/setup-git-server-over-http.txt 。经过 HTTP 推送的好处之一是你可使用任何 WebDAV 服务器，不须要为 Git 设定特殊环境；因此若是主机提供商支持经过 WebDAV 更新网站内容，你也可使用这项功能。

优势

      使用 HTTP 协议的好处是易于架设。几条必要的命令就可让全世界读取到仓库的内容。花费不过几分钟。HTTP 协议不会占用过多服务器资源。由于它通常只用到静态的 HTTP 服务提供全部数据，普通的 Apache 服务器平均每秒能支撑数千个文件的并发访问 — 哪怕让一个小型服务器超载都很难。

      你也能够经过 HTTPS 提供只读的仓库，这意味着你能够加密传输内容；你甚至能够要求客户端使用特定签名的 SSL 证书。通常状况下，若是到了这一步，使用 SSH 公共密钥多是更简单的方案；不过也存在一些特殊状况，这时经过 HTTPS 使用带签名的 SSL 证书或者其余基于 HTTP 的只读链接受权方式是更好的解决方案。

     HTTP 还有个额外的好处：HTTP 是一个如此常见的协议，以致于企业级防火墙一般都容许其端口的通讯。

缺点

      HTTP 协议的消极面在于，相对来讲客户端效率更低。克隆或者下载仓库内容可能会花费更多时间，并且 HTTP 传输的体积和网络开销比其余任何一个协议都大。由于它没有按需供应的能力 — 传输过程当中没有服务端的动态计算 — 于是 HTTP 协议常常会被称为_傻瓜（dumb）_协议。更多 HTTP 协议和其余协议效率上的差别见第 9 。

4.2  在服务器上部署 Git

       开始架设 Git 服务器前，须要先把现有仓库导出为裸仓库 — 即一个不包含当前工做目录的仓库。作法直截了当，克隆时用--bare 选项便可。裸仓库的目录名通常以.git 结尾，像这样：

$ git clone --bare my_project my_project.git 
Initialized empty Git repository in /opt/projects/my_project.git/

      该命令的输出或许会让人有些不解。其实 clone 操做基本上至关于 git init 加 git fetch，因此这里出现的实际上是git init 的输出，先由它创建一个空目录，而以后传输数据对象的操做并没有任何输出，只是悄悄在幕后执行。如今my_project.git 目录中已经有了一份 Git 目录数据的副本。

总体上的效果大体至关于：

$ cp -Rf my_project/.git my_project.git

     但在配置文件中有若干小改动，不过对用户来说，使用方式都同样，不会有什么影响。它仅取出 Git 仓库的必要原始数据，存放在该目录中，而不会另外建立工做目录。

把裸仓库移到服务器上

     有了裸仓库的副本后，剩下的就是把它放到服务器上并设定相关协议。假设一个域名为 git.example.com 的服务器已经架设好，并能够经过 SSH 访问，咱们打算把全部 Git 仓库储存在/opt/git 目录下。只要把裸仓库复制过去：

$ scp -r my_project.git user@git.example.com:/opt/git

     如今，全部对该服务器有 SSH 访问权限，并可读取 /opt/git 目录的用户均可以用下面的命令克隆该项目：

$ git clone user@git.example.com:/opt/git/my_project.git

      若是某个 SSH 用户对 /opt/git/my_project.git 目录有写权限，那他就有推送权限。若是到该项目目录中运行git init 命令，并加上 --shared 选项，那么 Git 会自动修改该仓库目录的组权限为可写（译注：实际上 --shared能够指定其余行为，只是默认为将组权限改成可写并执行 g+sx，因此最后会获得 rws。）。

$ ssh user@git.example.com 
$ cd /opt/git/my_project.git 
$ git init --bare --shared

      因而可知，根据现有的 Git 仓库建立一个裸仓库，而后把它放上你和同事都有 SSH 访问权的服务器是多么容易。如今已经能够开始在同一项目上密切合做了。

值得注意的是，这的的确确是架设一个少数人具备链接权的 Git 服务的所有 — 只要在服务器上加入能够用 SSH 登陆的账号，而后把裸仓库放在你们都有读写权限的地方。一切都准备停当，无需更多。

       下面的几节中，你会了解如何扩展到更复杂的设定。这些内容包含如何避免为每个用户创建一个帐户，给仓库添加公共读取权限，架设网页界面，使用 Gitosis 工具等等。然而，只是和几我的在一个不公开的项目上合做的话，仅仅是一个 SSH 服务器和裸仓库就足够了，记住这点就能够了。

小型安装

       若是设备较少或者你只想在小型开发团队里尝试 Git ，那么一切都很简单。架设 Git 服务最复杂的地方在于帐户管理。若是须要仓库对特定的用户可读，而给另外一部分用户读写权限，那么访问和许可的安排就比较困难。

SSH 链接

      若是已经有了一个全部开发成员均可以用 SSH 访问的服务器，架设第一个服务器将变得异常简单，几乎什么都不用作（正如上节中介绍的那样）。若是须要对仓库进行更复杂的访问控制，只要使用服务器操做系统的本地文件访问许可机制就好了。

      若是须要团队里的每一个人都对仓库有写权限，又不能给每一个人在服务器上创建帐户，那么提供 SSH 链接就是惟一的选择了。咱们假设用来共享仓库的服务器已经安装了 SSH 服务，并且你经过它访问服务器。

       有好几个办法可让团队的每一个人都有访问权.

第一个办法是给每一个人创建一个帐户，直截了当但略过繁琐。反复运行adduser 并给全部人设定临时密码可不是好玩的。

第二个办法是在主机上创建一个 git 帐户，让每一个须要写权限的人发送一个 SSH 公钥，而后将其加入 git 帐户的~/.ssh/authorized_keys 文件。这样一来，全部人都将经过 git 帐户访问主机。这丝绝不会影响提交的数据 — 访问主机用的身份不会影响提交对象的提交者信息。

另外一个办法是让 SSH 服务器经过某个 LDAP 服务，或者其余已经设定好的集中受权机制，来进行受权。只要每一个人都能得到主机的 shell 访问权，任何可用的 SSH 受权机制都能达到相同效果。

4.3  生成 SSH 公钥

       大多数 Git 服务器都会选择使用 SSH 公钥来进行受权。系统中的每一个用户都必须提供一个公钥用于受权，没有的话就要生成一个。生成公钥的过程在全部操做系统上都差很少。首先先确认一下是否已经有一个公钥了。SSH 公钥默认储存在帐户的主目录下的~/.ssh 目录。进去看看：

$ cd ~/.ssh 
$ ls authorized_keys2 id_dsa known_hosts config id_dsa.pub

关键是看有没有用 something 和 something.pub 来命名的一对文件，这个 something 一般就是 id_dsa 或id_rsa。有 .pub 后缀的文件就是公钥，另外一个文件则是密钥。假如没有这些文件，或者干脆连.ssh 目录都没有，能够用 ssh-keygen 来建立。该程序在 Linux/Mac 系统上由 SSH 包提供，而在 Windows 上则包含在 MSysGit 包里：

$ ssh-keygen 
Generating public/private rsa key pair. Enter file in which to save the key (/Users/schacon/.ssh/id_rsa): Enter p

它先要求你确认保存公钥的位置（.ssh/id_rsa），而后它会让你重复一个密码两次，若是不想在使用公钥的时候输入密码，能够留空。

如今，全部作过这一步的用户都得把它们的公钥给你或者 Git 服务器的管理员（假设 SSH 服务被设定为使用公钥机制）。他们只须要复制 .pub 文件的内容而后发邮件给管理员。公钥的样子大体以下：

$ cat ~/.ssh/id_rsa.pub 
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAklOUpkDHrfHY17SbrmTIpNLTGK9Tjom/BWDSU GPl+nafzlHDTYW7hdI4yZ5ew18J...

4.4  架设服务器

       如今咱们过一边服务器端架设 SSH 访问的流程。本例将使用 authorized_keys 方法来给用户受权。咱们还将假定使用相似 Ubuntu 这样的标准 Linux 发行版。首先，建立一个名为 ‘git’ 的用户，并为其建立一个.ssh 目录。

$ sudo adduser git 
$ su git 
$ cd 
$ mkdir .ssh

       接下来，把开发者的 SSH 公钥添加到这个用户的 authorized_keys 文件中。假设你经过电邮收到了几个公钥并存到了临时文件里。重复一下，公钥大体看起来是这个样子：

$ cat /tmp/id_rsa.john.pub 
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCB007n/ww+ouN4gSLKssMxXnBOvf9LGt4L ojG6rs6hPB09j9R/T17/x4lhJA

只要把它们逐个追加到 authorized_keys 文件尾部便可：

$ cat /tmp/id_rsa.john.pub >> ~/.ssh/authorized_keys 
$ cat /tmp/id_rsa.josie.pub >> ~/.ssh/authorized_keys 
$ cat /tmp/id_rsa...

       如今能够用 --bare 选项运行 git init 来创建一个裸仓库，这会初始化一个不包含工做目录的仓库。

$ cd /opt/git $ mkdir project.git 
$ cd project.git 
$ git --bare init

       这时，Join，Josie 或者 Jessica 就能够把它加为远程仓库，推送一个分支，从而把第一个版本的项目文件上传到仓库里了。值得注意的是，每次添加一个新项目都须要经过 shell 登入主机并建立一个裸仓库目录。咱们不妨以gitserver 做为git 用户及项目仓库所在的主机名。若是在网络内部运行该主机，并在 DNS 中设定 gitserver 指向该主机，那么如下这些命令都是可用的：

# 在 John 的电脑上 
$ cd myproject $ git init 
$ git add . 
$ git commit -m 'initial commit' 
$ git remote add origin git@gitserver/path/*.git
$ git push

这样，其余人的克隆和推送也同样变得很简单：

$ git clone git@gitserver:/opt/git/project.git 
$ vim README 
$ git commit -am 'fix for the README file' 
$ git push origin master

用这个方法能够很快捷地为少数几个开发者架设一个可读写的 Git 服务。

       做为一个额外的防范措施，你能够用 Git 自带的 git-shell 工具限制 git 用户的活动范围。只要把它设为git 用户登入的 shell，那么该用户就没法使用普通的 bash 或者 csh 什么的 shell 程序。编辑 /etc/passwd 文件：

$ sudo vim /etc/passwd

在文件末尾，你应该能找到相似这样的行：

git:x:1000:1000::/home/git:/bin/sh

把 bin/sh 改成 /usr/bin/git-shell （或者用 which git-shell 查看它的实际安装路径）。该行修改后的样子以下：

git:x:1000:1000::/home/git:/usr/bin/git-shell

如今 git 用户只能用 SSH 链接来推送和获取 Git 仓库，而不能直接使用主机 shell。尝试普通 SSH 登陆的话，会看到下面这样的拒绝信息：

$ ssh git@gitserver 
fatal: What do you think I am? A shell? Connection to gitserver closed.

4.5  公共访问

      匿名的读取权限该怎么实现呢？也许除了内部私有的项目以外，你还须要托管一些开源项目。或者由于要用一些自动化的服务器来进行编译，或者有一些常常变化的服务器群组，而又不想成天生成新的 SSH 密钥 — 总之，你须要简单的匿名读取权限。

     或许对小型的配置来讲最简单的办法就是运行一个静态 web 服务，把它的根目录设定为 Git 仓库所在的位置，而后开启本章第一节提到的 post-update 挂钩。这里继续使用以前的例子。假设仓库处于/opt/git 目录，主机上运行着 Apache 服务。重申一下，任何 web 服务程序均可以达到相同效果；做为范例，咱们将用一些基本的 Apache 设定来展现大致须要的步骤。

首先，开启挂钩：

$ cd project.git 
$ mv hooks/post-update.sample 
hooks/post-update 
$ chmod a+x hooks/post-update

      若是用的是 Git 1.6 以前的版本，则能够省略 mv 命令 — Git 是从较晚的版本才开始在挂钩实例的结尾添加 .sample 后缀名的。

post-update 挂钩是作什么的呢？其内容大体以下：

$ cat .git/hooks/post-update 
#!/bin/sh exec git-update-server-info

       意思是当经过 SSH 向服务器推送时，Git 将运行这个 git-update-server-info 命令来更新匿名 HTTP 访问获取数据时所须要的文件。

      接下来，在 Apache 配置文件中添加一个 VirtualHost 条目，把文档根目录设为 Git 项目所在的根目录。这里咱们假定 DNS 服务已经配置好，会把对.gitserver 的请求发送到这台主机：

ServerName git.gitserver DocumentRoot /opt/git Order allow, deny allow from all

另外，须要把 /opt/git 目录的 Unix 用户组设定为 www-data ，这样 web 服务才能够读取仓库内容，由于运行 CGI 脚本的 Apache 实例进程默认就是以该用户的身份起来的：

$ chgrp -R www-data /opt/git

重启 Apache 以后，就能够经过项目的 URL 来克隆该目录下的仓库了。

$ git clone http://git.gitserver/project.git

这一招可让你在几分钟内为至关数量的用户架设好基于 HTTP 的读取权限。另外一个提供非受权访问的简单方法是开启一个 Git 守护进程，不过这将要求该进程做为后台进程常驻 — 接下来的这一节就要讨论这方面的细节。

4.6  GitWeb

       如今咱们的项目已经有了可读可写和只读的链接方式，不过若是能有一个简单的 web 界面访问就更好了。Git 自带一个叫作 GitWeb 的 CGI 脚本，运行效果能够到http://git.kernel.org 这样的站点体验下（见图 4-1）。

    

    若是想看看本身项目的效果，不妨用 Git 自带的一个命令，可使用似 lighttpd 或 webrick 这样轻量级的服务器启动一个临时进程。若是是在 Linux 主机上，一般都预装了lighttpd ，能够到项目目录中键入 git instaweb 来启动。若是用的是 Mac ，Leopard 预装了 Ruby，因此webrick 应该是最好的选择。若是要用 lighttpd 之外的程序来启动

git instaweb，能够经过--httpd 选项指定：

$ git instaweb --httpd=webrick 
[2009-02-21 10:02:21] INFO WEBrick 1.3.1 [2009-02-21 10:02:21] INFO ruby 1.8.6 (2008-03-03)

      这会在 1234 端口开启一个 HTTPD 服务，随之在浏览器中显示该页，十分简单。关闭服务时，只需在原来的命令后面加上--stop 选项就能够了：

$ git instaweb --httpd=webrick --stop

若是须要为团队或者某个开源项目长期运行 GitWeb，那么 CGI 脚本就要由正常的网页服务来运行。一些 Linux 发行版能够经过 apt 或yum 安装一个叫作 gitweb 的软件包，不妨首先尝试一下。咱们将快速介绍一下手动安装 GitWeb 的流程。首先，你须要 Git 的源码，其中带有 GitWeb，并能生成定制的 CGI 脚本：

$ git clone git://git.kernel.org/pub/scm/git/git.git 
$ cd git/ 
$ make GITWEB_PROJECTROOT="/opt/git" \ prefix=/usr gitweb/gitw

注意，经过指定 GITWEB_PROJECTROOT 变量告诉编译命令 Git 仓库的位置。而后，设置 Apache 以 CGI 方式运行该脚本，添加一个 VirtualHost 配置：

ServerName gitserver DocumentRoot /var/www/gitweb Options ExecCGI +FollowSymLinks +SymLinksIfOwnerMatch AllowOverride All ord

不难想象，GitWeb 可使用任何兼容 CGI 的网页服务来运行；若是偏向使用其余 web 服务器，配置也不会很麻烦。如今，经过 http://gitserver 就能够在线访问仓库了，在http://git.server 上还能够经过 HTTP 克隆和获取仓库的内容。