Table of Contents
git服务器开源软件
在服务器上部署git
git clone –bare my_project my_project.git
其实 clone 操作基本上相当于 git init 加 git fetch。
通过git账户访问
第二个办法是在主机上建立一个 git 账户，让每个需要写权限的人发送一个 SSH 公钥，然后将其加入 git 账户的~/.ssh/authorized_keys 文件。这样一来，所有人都将通过 git 账户访问主机。这丝毫不会影响提交的数据 — 访问主机用的身份不会影响提交对象的提交者信息。
$ sudo adduser git
$ su git
$ cd
$ mkdir .ssh
只要把它们逐个追加到 authorized_keys 文件尾部即可：
$ cat tmp/id_rsa.john.pub >> ~.ssh/authorized_keys
$ cat tmp/id_rsa.josie.pub >> ~.ssh/authorized_keys
$ cat tmp/id_rsa.jessica.pub >> ~.ssh/authorized_keys
现在可以用 –bare 选项运行 git init 来建立一个裸仓库，这会初始化一个不包含工作目录的仓库。
$ cd /opt/git
$ mkdir project.git
$ cd project.git
$ git –bare init
这时，Join，Josie 或者 Jessica 就可以把它加为远程仓库，推送一个分支，从而把第一个版本的项目文件上传到仓库里了。值得注意的是，每次添加一个新项目都需要通过 shell 登入主机并创建一个裸仓库目录。
$ cd myproject
$ git init
$ git add .
$ git commit -m ‘initial commit’
$ git remote add origin git@gitserver:/opt/git/project.git
$ git push origin master
作为一个额外的防范措施，你可以用 Git 自带的 git-shell 工具限制 git 用户的活动范围。只要把它设为git 用户登入的 shell，那么该用户就无法使用普通的 bash 或者 csh 什么的 shell 程序。编辑 /etc/passwd 文件：
在其他人机子上可以直接clone
git clone git@gitserver:/opt/git/project.git
$ 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
gitweb
git自带的cgi脚本
git instaweb –httpd=lighttpd
repo
git仓库太大会导致git操作很慢，那么分成多个子项目，用repo来管理。
代码抽取
git cherry-pick <commit>
分支合并
git merge
git rebase <upstream> [<branch>]
rebase 可以让你看起来是基于最新的代码实现的改动。
git submodule
子模块允许你将一个git仓库当作另一个git仓库的子目录。
gitk
安装apt-get install gitk
git log –graph
可以添加到git的配置文件中
git help workflows
查看推荐的工作流
GITolite
Gitolite 是一款 Perl 语言开发的 Git 服务管理工具，通过公钥对用户进行认证，并能够通过配置文件对写操作进行基于分支和路径的的精细授权。GITolite 采用的是SSH协议，并需要使用公钥 验证。也就是说 GITolite会根据管理员预先定义好的设置，根据客户的SSH，对于来自不同客户端的请求进行权限控制，只读，或者读写，甚至于精确到某个文件夹，某个文件的权限。
gerrit
前面我们说到了对Gitolite是对于开发人员的一种授权，但一旦保证了授权，就能够保证版本库的稳定吗？如果获得授权的人乱搞代码，或者改错代码，那版本库照样会出现不稳定的情况的。就像前面在敏捷系列里面说到的一样，在代码改动之后，要引入code review (代码审阅，说code review 比较顺口，还是用code review吧)。在Clearcase条件下，code review是需要把别人的代码整进去版本库之后，再由code reviewer拿下来看的。于是在Google Android项目的开发过程当中，Google为GIT带来了又一个伟大的工具-Gerrit，也有人叫Gerrit2，因为现在用的Gerrit跟Google刚开始整的时候有很大的不同，我们暂且叫它Gerrit就可以。
Gerrit有两个很牛的功能，第一是权限管理，它提供了一个跟GITolite一样的功能，管理用户的读写权限。但它比GITolite好用，对权限的控制都在它提供的网页系统里面完成，不用push啥的！第二是Gerrit为GIT带来强制性的code review，除非你某某是管理员。任何的代码改动都需要有人approve之后，这个代码改动才有可能进入公共代码库，如果没有经过approve或者被人reject了，即使你已经push了五百年，这代码依旧进不了公共版本库。而且 相比起裸奔时代的code review，Gerrit提供一个在线review 的系统，所有的操作都在它提供的系统上面点点点就能搞定的。
首先我们来看看权限控制，Gerrit有10种不同的权限，其中有读写权限，code review的权限等等。每个权限的设置包括两部分：权限本身，以及权限授予的组。
Jenkins
如果用了Gerrit，那么每一个代码改动都要经过code review approve 并且要验证。code review还好说，可验证就麻烦了。如果每个改动都要人手拿到本地，至少去确保能编译通过吧，那谁都会疯了的！！！话说IT人的精品特质之一就是懒，所以有繁琐的地方
往往都会产生自动化 （这貌似也是工业能够向前发展，甚至于社会能够向前发展的一个因素哦，要发扬发扬）。Jenkins就应运而生了。
Jenkins， 曾用名Hudson，是基于Java开发的持续集成的工具。它能够自动监控到公共代码库的版本变更，并且执行我们预先定义好的动作。在动作完成之后，把动作执行的结果回传给有关部门！比如我们可以让Jenkins监听Gerrit上面的代码变更情况，看有没有人提出code review的请求。如果监听到请求，那么Jenkins就偷偷向Gerrit要那个人改了的代码，试着做一些编译以及单元测试。如果这人很牛叉，测试通过。那么Jenkins会告诉Gerrit ：“喂，这条友很牛哦，我向毛主席保证，TA的代码改动没有问题”，这时Gerrit就跑过去将这个review item的 verify设置为+1，如果不通过，那就铁面无私地给一个 verify-1.
git权限控制理解
从技术上讲，git可能永远也做不到类似svn的路径授权(读权限)
如果允许按照路径授权，则各个克隆的关系不再是平等的，有的内容多有的内容少，分布式的理念被破坏。
git的授权模型只能实现非零即一的方式，要不拥有全部写权限，要不没有写权限。
要么拥有全部库的读权限，o要么禁用。
看来git的保密性确实不好，要不一视同仁，大家都有全部代码，要不把代码分成多个库。
这样看来在公司内部使用git确实不太方便了。公司最基本的要求就是代码的保护。
Git对于写操作可以精细到目录和分支级别（使用Gitolite作为服务器）， 但作为分布式版本库控制系统，在设计上只能实现版本库量子化的读授权。 即某用户对整个版本库要么都能读，要么对整个版本库都不能读。
那么如何控制Git版本库的读授权呢？实际上Git可以通过子模组来实现细粒度的读授权。 即在项目需要精细授权的场合，将版本库拆分为多个Git版本库进行单独授权， 再使用子模组将多个版本库整合为一个。这个操作并不复杂，而且有助于实现项目的模块化。