Git笔记（17）协议-CSDN博客

本文为氢键H-H原创文章，未经允许请勿用于商业用途，转载请注明出处

本文链接：https://blog.csdn.net/qq_32618327/article/details/104308807

Git笔记（17）协议

1. Git 服务器
2. 本地协议
3. HTTP 协议
4. SSH协议
5. Git 协议

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. 优点

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

2.3. 缺点

通常共享文件系统比较难配置
不能保护仓库避免意外的损坏
因为每一个用户都有“远程”目录的完整 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. 优点

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

3.3. 缺点

架设 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. 优势

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

4.2. 缺点

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

5. Git 协议

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

5.1. 应用场景

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

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

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

5.2. 优点

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

5.3. 缺点

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

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