GIT培训教程

GIT基本

基本简介

2005年，Linus花了两周时间自己用C写了一个分布式版本控制系统，这就是Git！一个月之内，Linux系统的源码已经由Git管理了！
Git是目前世界上最先进的分布式版本控制系统（没有之一）。

集中式VS分布式

CVS及SVN都是集中式的版本控制系统，而Git是分布式版本控制系统，集中式和分布式版本控制系统有什么区别呢？

集中式版本控制系统，版本库是集中存放在中央服务器的，而干活的时候，用的都是自己的电脑，所以要先从中央服务器取得最新的版本，然后开始干活，干完活了，再把自己的活推送给中央服务器。

那分布式版本控制系统与集中式版本控制系统有何不同呢？

首先，分布式版本控制系统根本没有“中央服务器”，每个人的电脑上都是一个完整的版本库，这样，你工作的时候，就不需要联网了，因为版本库就在你自己的电脑上。既然每个人电脑上都有一个完整的版本库，那多个人如何协作呢？比方说你在自己电脑上改 了文件A，你的同事也在他的电脑上改了文件A，这时，你们俩之间只需把各自的修改推送给对方，就可以互相看到对方的修改了。

和集中式版本控制系统相比，分布式版本控制系统的安全性要高很多，因为每个人电脑里都有完整的版本库，某一个人的电脑坏掉了不要紧，随便从其他人那里复制一个就可以了。而集中式版本控制系统的中央服务器要是出了问题，所有人都没法干活了。

Git安装

Linux上安装

如果要在 Linux 上安装预编译好的 Git 二进制安装包，可以直接用系统提供的包管理工具。在 Fedora 上用 yum 安装：

sudo yum install git

在 Ubuntu 这类 Debian 体系的系统上，可以用 apt-get 安装：

sudo apt-get install git-core。

Windows上安装

在 Windows 上安装 Git 同样轻松，有个叫做 msysGit 的项目提供了安装包，可以从 Google Code 的页面上下载安装文件（.exe），然后按默认选项安装即可。安装完成后，在开始菜单里找到“Git”->“Git Bash”，蹦出一个类似命令行窗口的东西，就说明Git安装成功！

GIT版本库

创建版本库

什么是版本库呢？版本库又名仓库，英文名repository，你可以简单理解成一个目录，这个目录里面的所有文件都可以被Git管理起来，每个文件的修改、删除，Git都能跟踪，以便任何时刻都可以追踪历史，或者在将来某个时刻可以“还原”。所以，创建一个版本库非常简单:

## 新创建一个测试目录mkdir dev_gitcd dev_git## 将目录初始化为git项目git init

瞬间Git就把仓库建好了，而且告诉你是一个空的仓库（empty Git repository），细心的哥们可以发现当前目录下多了一个.git的目录，这个目录是Git来跟踪管理版本库的，没事千万不要手动修改这个目录里面的文件，不然改乱了，就把Git仓库给破坏了。

添加文件到版本库

添加文件到Git仓库，分两步：
第一步，使用命令git add ，注意，可反复多次使用，添加多个文件；
第二步，使用命令git commit，完成。

## 创建一个文件touch readme.txt## 用git管理该文件git add .ORgit add -AORgit add pathto/filename## 将变动提交到git的本地缓存git comnit -m "your change log"OR git commit pathto/filename -m "declare the file and your change log"

简单解释一下git commit命令，-m 后面输入的是本次提交的说明，可以输入任意内容，当然最好是有意义的，这样你就能从历史记录里方便地找到改动记录。

git commit命令执行成功后会告诉你，1个文件被改动（我们新添加的readme.txt文件），插入了一行内容（readme.txt有一行内容）。

查看状态与修改内容

我们已经成功地添加并提交了一个readme.txt文件，现在，我们继续修改readme.txt文件，改成如下内容：

现在，运行git status命令看看结果：

git status命令可以让我们时刻掌握仓库当前的状态，上面的命令告诉我们，readme.txt被修改过了，但还没有准备提交的修改。虽然Git告诉我们readme.txt被修改了，但如果能看看具体修改了什么内容，自然是很好的。

比如你休假两周从国外回来，第一天上班时，已经记不清上次怎么修改的readme.txt，所以，需要用git diff这个命令看看：

git diff顾名思义就是查看difference，显示的格式正是Unix通用的diff格式，可以从上面的命令输出看到，我们添加了2行。

知道了对readme.txt作了什么修改后，再把它提交到仓库就放心多了，提交修改和提交新文件是一样的两步，第一步是git add，第二部是git commit。提交之前可以看下当前仓库的状态：

git status
告诉我们，将要被提交的修改包括readme.txt，下一步，就可以放心地提交了，提交后再次查看状态：

Git告诉我们当前没有需要提交的修改，而且，工作目录是干净（working directory clean）的。

版本回退

你不断对文件进行修改，然后不断提交修改到版本库里，就好比玩RPG游戏时，每通过一关就会自动把游戏状态存盘，如果某一关没过去，你还可以选择读取前一 关的状态。有些时候，在打Boss之前，你会手动存盘，以便万一打Boss失败了，可以从最近的地方重新开始。Git也是一样，每当你觉得文件修改到一定程度的时候，就可以“保存一个快照”，这个快照在Git中被称为commit。一旦你把文件改乱了，或者误删了文件，还可以从最近的一个commit恢复，然后继续工作，而不是把几个月的工作成果全部丢失。查看历史记录我们用git log命令:

git log

命令显示从最近到最远的提交日志，我们可以看到3次提交，最近的一次是“add a word dist”，上一次是“modify readme”，最早的一次是“new file readme”。 如果嫌输出信息太多，看得眼花缭乱的，可以试试加上
–pretty=oneline参数：

需要友情提示的是，你看到的一大串类似“ 7a7205..461e0b”的是commit id（版本号），和SVN不一样，Git的commit id不是1，2，3……递增的数字，而是一个SHA1计算出来的一个非常大的数字，用十六进制表示，而且你看到的commit id和我的肯定不一样，以你自己的为准。为什么commit id需要用这么一大串数字表示呢？因为Git是分布式的版本控制系统，后面我们还要研究多人在同一个版本库里工作，如果大家都用1，2，3……作为版本 号，那肯定就冲突了。

好了，现在我们准备把readme.txt回退到上一个版本，也就是“modify readme”的那个版本，怎么做呢？

首先，Git必须知道当前版本是哪个版本，在Git中，用HEAD表示当前版本，也就是最新的提交“7a7205..461e0b”（注意我的提交ID和你的肯定不一样），上一个版本就是HEAD^，上上一个版本就是HEAD^^，当然往上100 个版本写100个^比较容易数不过来，所以写成HEAD~100。
现在，我们要把当前版本“add a word dist”回退到上一个版本“modify readme”，就可以使用git reset命令。

git reset命令有3种方式：
1. git reset --mixed : 此为默认方式，不带任何参数的git reset，就是这种方式，它回退到某个版本，只保留源码，回退commit和index信息。
2. git reset --soft : 回退到某个版本，只回退了commit的信息，不会恢复到index file一级。如果还要提交，直接commit即可。
3. git reset --hard : 彻底回退到某个版本，本地的源码也会变成回退版本的内容。

在Git中，总是有后悔药可以吃的。当你用git reset --hard HEAD^回退到“modify readme”版本时，再想恢复到“add a word dist”，就必须找到“add a word dist”的commit id。Git提供了一个命令git reflog用来记录你的每一次命令。

工作区和暂存区

工作区（Working Directory）：就是你在电脑里能看到的目录，比如我的zhaozw文件夹就是一个工作区。

版本库（Repository）：工作区有一个隐藏目录“.git”，这个不算工作区，而是Git的版本库。
Git的版本库里存了很多东西，其中最重要的就是称为stage（或者叫index）的暂存区，还有Git为我们自动创建的第一个分支master，以及指向master的一个指针叫HEAD。

对于任何一个文件，在 Git 内都只有三种状态：
- 已提交（committed）已提交表示该文件已经被安全地保存在本地数据库中了；
- 已修改（modified）已修改表示修改了某个文件，但还没有提交保存；
- 已暂存（staged）。已暂存表示把已修改的文件放在下次提交时要保存。

管理修改

下面，我们要讨论的就是，为什么Git比其他版本控制系统设计得优秀，因为Git跟踪并管理的是修改，而非文件。

你会问，什么是修改？比如你新增了一行，这就是一个修改，删除了一行，也是一个修改，更改了某些字符，也是一个修改，删了一些又加了一些，也是一个修改，甚至创建一个新文件，也算一个修改。

为什么说Git管理的是修改，而不是文件呢？

我们还是做实验。第一步，对readme.txt做一个修改，比如加一行内容，然后，添加，然后，再修改readme.txt，再提交，提交后查看状态：

可以看出第二次我的修改没有被提交，现在我们回顾下操作过程：

第一次修改 -> git add -> 第二次修改 -> git commit

我们前面讲了，Git管理的是修改，当你用“git add”命令后，在工作区的第一次修改被放入暂存区，准备提交，但是，在工作区的第二次修改并没有放入暂存区，所以，“git commit”只负责把暂存区的修改提交了，也就是第一次的修改被提交了，第二次的修改不会被提交。

git diff HEAD -- readme.txt命令可以查看工作区与版本库里面最新版本的区别。

那怎么提交第二次修改呢？

你可以继续add再commit，也可以别着急提交第一次修改，先add第二次修改，再commit，就相当于把两次修改合并后一块提交了：
第一次修改 -> add -> 第二次修改 -> add -> commit。

撤销修改

git checkout -- file

可以丢弃工作区的修改，意思就是，把readme.txt文件在工作区的修改全部撤销，这里有两种情况：
- 一种是readme.txt自修改后还没有被放到暂存区，现在，撤销修改就回到和版本库一模一样的状态
- 一种是readme.txt已经添加到暂存区后，又作了修改，现在，撤销修改就回到添加到暂存区后的状态。总之，就是让这个文件回到最近一次git commit或git add时的状态。

git checkout -- file

命令中的“–”很重要，没有“–”，就变成了“创建一个新分支”的命令，我们在后面的分支管理中会再次遇到git checkout命令。

git reset HEAD file

可以把暂存区的修改撤销掉（unstage），重新放回工作区。

删除文件

在Git中，删除也是一个修改操作。我们实战一下，先添加一个新文件test.txt到Git并且提交。

一般情况下，你通常直接在文件管理器中把没用的文件删了，或者用rm命令删了，这个时候，Git知道你删除了文件。因此，工作区和版本库就不一致了，git status命令会立刻告诉你哪些文件被删除了。

现在你有两个选择，一是确实要从版本库中删除该文件，那就用命令git rm删掉，并且commit。
另一种情况是删错了，因为版本库里还有呢，所以可以很轻松地把误删的文件恢复到最新版本，用git checkout -- file恢复文件就行。

git checkout其实是用版本库里的版本替换工作区的版本，无论工作区是修改还是删除，都可以“一键还原”。

远程仓库

Git是分布式版本控制系统，同一个Git仓库，可以分布到不同的机器上。

怎么分布呢？

最早，肯定只有一台机器有一个原始版本库，此后，别的机器可以“克隆”这个原始版本库，而且每台机器的版本库其实都是一样的，并没有主次之分。实际情况往往是这样，找一台电脑充当服务器的角色，每天24小时开机，其他每个人都从这个“服务器”仓库克隆一份到自己的电脑上，并且各自把各自的提交推送到服务器仓库里，也从服务器仓库中拉取别人的提交。

注册一个GitHub账号，就可以免费获得Git远程仓库。由于你的本地Git仓库和GitHub仓库之间的传输是通过SSH加密的，所以，需要一点设置：
- 第1步：创建SSH Key。在用户主目录下，看看有没有.ssh目录，如果有，再看看这个目录下有没有id_rsa和id_rsa.pub这两个文件，如果已经有了，可直接 跳到下一步。如果没有，打开Shell（Windows下打开Git Bash），创建SSH Key：

``` ssh-keygen -t rsa -C "[e-mail]"```

你需要把邮件地址换成你自己的邮件地址，然后一路回车，都使用默认值即可。由于这个Key也不是用于军事目的，所以也无需设置密码。如果一切顺利的话，可以在用户主目录里找到.ssh目录，里面有id_rsa和id_rsa.pub两个文件，这两个就是SSH Key的秘钥对。id_rsa是私钥，不能泄露出去，id_rsa.pub是公钥，可以放心地告诉任何人。
- 第2步：登陆GitHub，打开“Account settings”，“SSH Keys”页面，然后，点“Add SSH Key”，填上任意Title，在Key文本框里粘贴id_rsa.pub文件的内容。

为什么GitHub需要SSH Key呢？因为GitHub需要识别出你推送的提交确实是你推送的，而不是别人冒充的，而Git支持SSH协议，所以，GitHub只要知道了你的公钥，就可以确认只有你自己才能推送。

添加远程库

要添加一个新的远程仓库，可以指定一个简单的名字，以便将来引用，运行

git remote add[shortname] [url]。

git remote 可以查看当前配置有哪些远程仓库，也可以加上-v选项，显示对应的克隆地址。

分布式版本系统的最大好处之一是在本地工作完全不需要考虑远程库的存在，也就是有没有联网都可以正常工作，而SVN在没有联网的时候是拒绝提交代码的！当有网络的时候，再把本地提交推送一下就完成了同步，真是太方便了！

从远程库克隆

从远程库克隆用git clone命令，现在，我们从GitHub上克隆一个本地库：

git clone [e-mail]:vickyi/resume.git

如果有多个人协作开发，那么每个人各自从远程克隆一份就可以了，你也许还注意到，GitHub给出的地址不止一个，还可以用https://github.com/michaelliao/gitskills.git这样的地址。实际上，Git支持多种协议，默认的git://使用ssh，但也可以使用https等其他协议。使用https除了速度慢以外，还有个最大的麻烦是每次推送都必须输入口令，但是在某些只开放http端口的公司内部就无法使用ssh协议而只能用https。

抓取与推送数据到远程库

抓取数据

可以用

git fetch remote-nameORgit pull remote-name

命令从远程仓库抓取数据到本地。两者不同：
- git pull，相当于git fetch+git merge。
- git fetch命令会到远程仓库中拉取所有你本地仓库中还没有的数据。

运行完成后，你就可以在本地访问该远程仓库中的所有分支，将其中某个分支合并到本地，或者只是取出某个分支，一探究竟。有一点很重要，需要记住，fetch 命令只是将远端的数据拉到本地仓库，并不自动合并到当前工作分支，只有当你确实准备好了，才能手工合并。git pull命令自动抓取数据下来，然后将远端分支自动合并到本地仓库中当前分支。

推送数据

项目进行到一个阶段，要同别人分享目前的成果，可以将本地仓库中的数据推送到远程仓库。实现这个任务的命令很简单：

git push [remote-name] [branch-name]

如果要把本地的 master 分支推送到origin服务器上（再次说明下，克隆操作会自动使用默认的 master 和 origin 名字），可以运行下面的命令：

git push origin master

其他一些操作

查看远程仓库信息

我们可以通过命令

git remote show [remote-name]

查看某个远程仓库的详细信息，比如要看所克隆的origin仓库，可以运行：

git remote show origin

远程仓库的删除和重命名

在Git 中可以用

git remote rename

命令修改某个远程仓库的简短名称，比如想把pb改成paul，可以这么运行：

git remote rename pb paul

注意，对远程仓库的重命名，也会使对应的分支名称发生变化，原来的origin/master分支现在成了myorigin/master。

碰到远端仓库服务器迁移，或者原来的克隆镜像不再使用，又或者某个参与者不再贡献代码，那么需要移除对应的远端仓库，可以运行命令:

git remote rm

分支管理

分支就是科幻电影里面的平行宇宙，当你正在电脑前努力学习Git的时候，另一个你正在另一个平行宇宙里努力学习SVN。如果两个平行宇宙互不干扰，那对现在的你也没啥影响。不过，在某个时间点，两个平行宇宙合并了，结果，你既学会了Git又学会了SVN！

分支在实际中有什么用呢？

假设你准备开发一个新功能，但是需要两周才能完成，第一周你写了50%的代码，如果立刻提交，由于代码还没写完，不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交，又存在丢失每天进度的巨大风险。现在有了分支，就不用怕了。你创建了一个属于你自己的分支，别人看不到，还继续在原来的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样，既安全，又不影响别人工作。其他版本控制系统如SVN等都有分支管理，但是用过之后你会发现，这些版本控制系统创建和切换分支比蜗牛还慢，简直让人无法忍受，结果分支功能成了摆设，大家都不去用。但Git的分支是与众不同的，无论创建、切换和删除分支，Git在1秒钟之内就能完成！无论你的版本库是1个文件还是1万个文件。

Git 中的分支，其实本质上仅仅是个指向 commit 对象的可变指针。Git 会使用 master 作为分支的默认名字。在若干次提交后，你其实已经有了一个指向最后一次提交对象的 master 分支，它在每次提交的时候都会自动向前移动。

创建于合并分支

• 查看分支：git branch
• 创建分支：git branch name
• 切换分支：git checkout name
• 创建+切换分支：git checkout -b name
• 合并某分支到当前分支：git merge name
• 删除分支：git branch -d name

一开始的时候，master分支是一条线，Git用master指向最新的提交，再用HEAD指向master，就能确定当前分支，以及当前分支的提交点：

每次提交，master分支都会向前移动一步，这样，随着你不断提交，master分支的线也越来越长。

当我们创建新的分支，例如dev时，Git新建了一个指针叫dev，指向master相同的提交，再把HEAD指向dev，就表示当前分支在dev上：

你看，Git创建一个分支很快，因为除了增加一个dev指针，改改HEAD的指向，工作区的文件都没有任何变化！

不过，从现在开始，对工作区的修改和提交就是针对dev分支了，比如新提交一次后，dev指针往前移动一步，而master指针不变：

所以Git合并分支也很快！就改改指针，工作区内容也不变！
合并完分支后，甚至可以删除dev分支。删除dev分支就是把dev指针给删掉，删掉后，我们就剩下了一条master分支：

git branch -d dev

下面是例子:
首先创建分支dev

git chckout -b devORgit branch devgit checkout dev

然后创建文件spring.txt，再添加提交，dev分支下有spring.txt，切换到master主分支上,没有spring.txt文件。

现在我们合并dev分支到主分支上看看：

git checkout mastergit merge dev

git merge命令用于合并指定分支到当前分支。合并后，再查看spring.txt的内容，就可以看到，和dev分支的最新提交是完全一样的。

请注意，合并时出现了 “Fast forward”（快进）提示。由于当前 master 分支所在的 commit 是要并入的 dev分支的直接上游，Git 只需把指针直接右移。换句话说，如果顺着一个分支走下去可以到达另一个分支，那么 Git 在合并两者时，只会简单地把指针前移，因为没有什么分歧需要解决，所以这个过程叫做快进（Fast forward）。

当然，也不是每次合并都能Fast-forward，我们后面会将其他方式的合并。
合并完成后，就可以放心地删除dev分支了，删除后查看就只剩下master分支了：

git branch -a

因为创建、合并和删除分支非常快，所以Git鼓励你使用分支完成某个任务，合并后再删掉分支，这和直接在master分支上工作效果是一样的，但过程更安全。

通常，合并分支时，如果可能，Git会用“Fast forward”模式，但这种模式下，删除分支后，会丢掉分支信息。

如果要强制禁用“Fast forward”模式，Git就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息。请注意–no-ff参数，表示禁用“Fast forward”。

解决冲突

当Git无法自动合并分支时，就必须首先解决冲突。解决冲突后，再提交，合并完成。下面我们举例，新建分支dev,分别在dev与master分支上对spring.txt文件第一行进行修改，分别添加提交后，合并dev到master：

果然冲突了！Git告诉我们，spring.txt文件存在冲突，必须手动解决冲突后再提交。git status也可以告诉我们冲突的文件：

我们可以直接查看spring.txt的内容：

Git用<<<<<<<，=======，>>>>>>>标记出不同分支的内容，我们修改如下后保存，再提交。

分支管理

到目前为止，你已经学会了如何创建、合并和删除分支。除此之外，我们还需要学习如何管理分支，在日后的常规工作中会经常用到下面介绍的管理命令。git branch命令不仅仅能创建和删除分支，如果不加任何参数，它会给出当前所有分支的清单，若要查看各个分支最后一次 commit 信息，运行

git branch -v

要从该清单中筛选出你已经（或尚未）与当前分支合并的分支，可以用–merge和–no-merged选项（Git1.5.6 以上版本）比如

git branch -merge

查看哪些分支已被并入当前分支，可以用

git branch --no-merged

查看尚未合并的工作。我们会看到其余还未合并的分支。因为其中还包含未合并的工作，用

git branch -d

删除该分支会导致失败，可以用

git branch -D

强制删除。

BUG分支

软件开发中，bug就像家常便饭一样。有了bug就需要修复，在Git中，由于分支是如此的强大，所以，每个bug都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。当你接到一个修复一个代号101的bug的任务时，很自然地，你想创建一个分支issue -101来修复它，但是，等等，当前正在dev上进行的工作还没有提交，并不是你不想提交，而是工作只进行到一半，还没法提交，预计完成还需1天时间。但是，必须在两个小时内修复该bug，怎么办？幸好，Git还提供了一个stash功能，可以把当前工作现场“储藏”起来，等以后恢复现场后继续工作：

git stash

现在，用git status查看工作区，就是干净的（除非有没有被Git管理的文件），因此可以放心地创建分支来修复bug。首先确定要在哪个分支上修复bug，假定需要在master分支上修复，就从master创建临时分支，修复完bug后，回到dev分支，查看状态，工作区是干净的，刚才的工作现场存到哪去了？用命令看看：

git stash list

工作现场还在，Git把stash内容存在某个地方了，但是需要恢复一下，有两个办法：
- 一是用

git stash apply

恢复，但是恢复后，stash内容并不删除，你需要用

# 恢复后，stash内容并不删除git stash list## 将stash内容删除git stash drop

来删除
- 另一种方式是用

git stash pop

恢复，同时把stash内容也删了，再用git stash list，就看不到任何stash内容了：

标签管理

发布一个版本时，我们通常先在版本库中打一个标签，这样，就唯一确定了打标签时刻的版本。将来无论什么时候，取某个标签的版本，就是把那个打标签的时刻的历史版本取出来。所以，标签也是版本库的一个快照。
Git的标签虽然是版本库的快照，但其实它就是指向某个commit的指针（跟分支很像对不对？但是分支可以移动，标签不能移动），所以，创建和删除标签都是瞬间完成的。

创建标签

git tag name

用于新建一个标签，默认为HEAD，也可以指定一个commit id；

git tag -a tagname -m "blablabla..."

可以指定标签信息，用-a指定标签名，-m指定说明文字；

git tag -s tagname -m "blablabla..."

可以用PGP签名标签；

git show tagname

可以看到标签说明文字；

git tag

可以查看所有标签；

操作标签

如果标签打错了，也可以删除，用

git tag -d tagname

因为创建的标签都只存储在本地，不会自动推送到远程。所以，打错的标签可以在本地安全删除。如果要推送某个标签到远程，使用命令

git push origin tagname

或者，一次性推送全部尚未推送到远程的本地标签用

git push origin --tags

如果标签已经推送到远程，要删除远程标签就麻烦一点，先从本地删除，然后，从远程删除。删除命令也是push，但是格式为

git push origin  :refs/tags/tagname

自定义Git

忽略特殊文件

有些时候，你必须把某些文件放到Git工作目录中，但又不能提交它们，比如保存了数据库密码的配置文件啦，等等，每次git status都会显示“Untracked files …”，有强迫症的童鞋心里肯定不爽。

好在Git考虑到了大家的感受，这个问题解决起来也很简单，在Git工作区的根目录下创建一个特殊的.gitignore文件，然后把要忽略的文件名填进去，Git就会自动忽略这些文件。

不需要从头写.gitignore文件，GitHub已经为我们准备了各种配置文件，只需要组合一下就可以使用了。所有配置文件可以直接在线浏览：https://github.com/github/gitignore。

配置别名

有没有经常敲错命令？比如git status？status这个单词真心不好记。
如果敲git st就表示git status那就简单多了，当然这种偷懒的办法我们是极力赞成的。

我们只需要敲一行命令，告诉Git，以后st就表示status，可以配置别名：

git config --global alias.st status

格式为：

git config --global aloas.别名 原名

搭建GIT服务器

搭建Git服务器需要准备一台运行Linux的机器，强烈推荐用Ubuntu或Debian，这样，通过几条简单的apt命令就可以完成安装。
- 第一步，安装git：sudo apt-get install git
- 第二步，创建一个git用户，用来运行git服务
- 第三步，创建证书登录：收集所有需要登录的用户的公钥，就是他们自己的id_rsa.pub文件，把所有公钥导入到/home/git/.ssh/authorized_keys文件里，一行一个。
- 第四步，初始化Git仓库：先选定一个目录作为Git仓库，假定是/srv/sample.git，在/srv目录下输入命令：

sudo git init --bare sample.git

Git就会创建一个裸仓库，裸仓库没有工作区，因为服务器上的Git仓库纯粹是为了共享，所以不让用户直接登录到服务器上去改工作区，并且服务器上的Git仓库通常都以.git结尾。然后，把owner改为git：

sudo chown -R git:git sample.git

• 第五步，禁用shell登录：
  出于安全考虑，第二步创建的git用户不允许登录shell，这可以通过编辑/etc/passwd文件完成
• 第六步，克隆远程仓库