Git笔记（17）协议

雨点打透心脏的1/2处 2023-07-05 10:26 4阅读 0赞

### Git笔记（17） 协议 ###

*  1. Git 服务器
 *  2. 本地协议
 *   *  2.1. 应用场景
     *  2.2. 优点
     *  2.3. 缺点
 *  3. HTTP 协议
 *   *  3.1. 智能 HTTP 协议
     *  3.2. 优点
     *  3.3. 缺点
 *  4. SSH协议
 *   *  4.1. 应用场景
     *  4.1. 优势
     *  4.2. 缺点
 *  5. Git 协议
 *   *  5.1. 应用场景
     *  5.2. 优点
     *  5.3. 缺点

--------------------

# 1. Git 服务器 #

为了使用 Git 协作功能，还需要有远程的 Git 仓库  
与他人合作的最佳方法即是建立一个你与合作者们都有权利访问  
且可从那里推送和拉取资料的共用仓库

架设一台 Git 服务器并不难  
首先，选择服务器使用的通讯协议

一个远程仓库通常只是一个裸仓库（**bare repository**）  
即一个没有当前工作目录的仓库  
因为该仓库仅仅作为合作媒介，不需要从磁盘检查快照，存放的只有 Git 的资料  
简单的说，裸仓库就是工程目录内的 `.git` 子目录内容，不包含其他资料

Git 可以使用四种主要的协议来传输资料：

*  本地协议（Local）
 *  HTTP 协议
 *  SSH（Secure Shell）协议
 *  Git 协议

--------------------

# 2. 本地协议 #

最基本的就是本地协议（**Local protocol**）  
其中的远程版本库就是 **硬盘内的另一个目录**

--------------------

## 2.1. 应用场景 ##

这常见于团队每一个成员都对一个共享的文件系统拥有访问权  
或者比较少见的多人共用同一台电脑的情况

如果使用共享文件系统  
就可以从本地版本库克隆（`clone`）、推送（`push`）以及拉取（`pull`）

例如，克隆一个本地版本库，可以执行如下的命令：

$ git clone /opt/git/project.git

如果仅是指定路径，Git 会尝试使用硬链接（`hard link`）或直接复制所需要的文件

或可以执行这个命令：

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

如果指定 `file://`，Git 会触发平时用于 **网路传输资料的进程**，那通常是传输效率较低的方法

> 但取得一个没有外部参考（**extraneous references**）或对象（**object**）的**干净版本库副本**

通常是在从其他版本控制系统导入后或一些类似情况需要这么做  
在此将使用普通路径，因为这样通常更快

要增加一个本地版本库到现有的 Git 项目，可以执行如下的命令：

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

然后，就可以像在网络上一样从远端版本库推送和拉取更新了

--------------------

## 2.2. 优点 ##

1.  简单
2.  直接使用了现有的文件权限和网络访问权限  
    只需要像设置其他共享目录一样  
    把一个裸版本库的副本放到都可以访问的路径，并设置好读/写的权限即可
3.  这也是快速从别人的工作目录中拉取更新的方法  
    如果和别人一起合作一个项目，他想让你从版本库中拉取更新时  
    运行类似 `git pull /home/john/project` 的命令比推送到服务器再取回简单多了

--------------------

## 2.3. 缺点 ##

1.  通常共享文件系统比较难配置
2.  不能保护仓库避免意外的损坏  
    因为每一个用户都有“远程”目录的完整 shell 权限  
    没有方法可以阻止他们修改或删除 Git 内部文件和损坏仓库

--------------------

# 3. HTTP 协议 #

Git 通过 HTTP 通信有两种模式  
在 Git 1.6.6 版本之前只有一个方式可用，十分简单并且通常是只读模式的  
Git 1.6.6 版本引入了一种新的、更智能的协议  
让 Git 可以像通过 SSH 那样智能的协商和传输数据

--------------------

## 3.1. 智能 HTTP 协议 ##

智能 HTTP 协议或许是最流行的使用 Git 的方式

运行方式和 SSH 及 Git 协议类似  
只是运行在标准的 HTTP/S 端口上并且可以使用各种 HTTP 验证机制  
这意味着使用起来会比 SSH 协议简单的多  
比如可以使用 HTTP 协议的用户名／密码的基础授权，免去设置 SSH 公钥

它即支持像 git:// 协议一样设置匿名服务  
也可以像 SSH 协议一样提供传输时的授权和加密  
而且只用一个 URL 就可以都做到，省去了为不同的需求设置不同的 URL  
如果要推送到一个需要授权的服务器上，服务器会提示你输入用户名和密码  
从服务器获取数据时也一样

事实上，类似 GitHub 的服务，在网页上看到的 URL  
和在克隆、推送（如果有权限）时使用的是一样的

--------------------

## 3.2. 优点 ##

1.  不同的访问方式只需要一个 URL
2.  服务器只在需要授权时提示输入授权信息
3.  可以在 HTTPS 协议上提供只读版本库的服务
4.  可以让客户端使用指定的 SSL 证书
5.  一般的企业防火墙都会允许这些端口的数据通过

--------------------

## 3.3. 缺点 ##

1.  架设 HTTP/S 协议的服务端会比 SSH 协议的棘手一些

--------------------

# 4. SSH协议 #

SSH 协议也是一个验证授权的网络协议  
并且，因为其普遍性，架设和使用都很容易

--------------------

## 4.1. 应用场景 ##

之前架设 Git 服务器时常用 SSH 协议作为传输协议  
因为大多数环境下服务器已经支持通过 SSH 访问

通过 SSH 协议克隆版本库，可以指定一个 `ssh://` 的 URL：

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

或者使用一个简短的 scp 式的写法：

$ git clone user@server:project.git

也可以不指定用户，Git 会使用当前登录的用户名

--------------------

## 4.1. 优势 ##

1.  SSH 架设相对简单
2.  通过 SSH 访问是安全的，所有传输数据都要经过授权和加密
3.  SSH 协议很高效，在传输前也会尽量压缩数据

--------------------

## 4.2. 缺点 ##

1.  不能通过他实现匿名访问  
    如果只在公司网络使用，SSH 协议可能是唯一要用到的协议

--------------------

# 5. Git 协议 #

这是包含在 Git 里的一个特殊的守护进程  
它监听在一个**特定的端口（9418）**，类似于 SSH 服务  
但是访问无需任何授权

--------------------

## 5.1. 应用场景 ##

要让版本库支持 Git 协议，需要先创建一个 `git-daemon-export-ok` 文件  
它是 Git 协议守护进程为这个版本库提供服务的必要条件

但是除此之外没有任何安全措施  
要么谁都可以克隆这个版本库，要么谁也不能  
这意味着，通常不能通过 Git 协议推送

由于没有授权机制，一旦开放推送操作  
意味着网络上知道这个项目 URL 的人都可以向项目推送数据  
不用说，极少会有人这么做

--------------------

## 5.2. 优点 ##

1.  目前，Git 协议是 Git 使用的网络传输协议里最快的
2.  使用与 SSH 相同的数据传输机制，但是省去了加密和授权的开销

--------------------

## 5.3. 缺点 ##

1.  缺乏授权机制  
    一般的做法里，会同时提供 SSH 或者 HTTPS 协议的访问服务  
    只让少数几个开发者有推送（写）权限，其他人通过 `git://` 访问只有读权限
2.  最难架设  
    要求有自己的守护进程，这就要配置 xinetd 或者其他的程序，这些工作并不简单
3.  要求防火墙开放 9418 端口  
    但是企业防火墙一般不会开放这个非标准端口

--------------------

参考： [git][]  
以上内容，均根据git官网介绍删减、添加和修改组成

--------------------