举例来说，在项目中使用命令 git push origin master 时, origin 是由基于 SSH 协议的 URL 所定义的。 Git 会运行 send-pack 进程，它会通过 SSH 连接你的服务器。 它会尝试通过 SSH 在服务端执行命令，就像这样：

git-receive-pack 命令会立即为它所拥有的每一个引用发送一行响应——在这个例子中，就只有 master分支和它的 SHA-1 值。 第一行响应中也包含了一个服务端能力的列表（这里是 report-status、delete-refs 和一些其它的，包括客户端的识别码）。

每一行以一个四位的十六进制值开始，用于指明本行的长度。 你看到第一行以 005b 开始，这在十六进制中表示 91，意味着第一行有 91 字节。 下一行以 003e 起始，也就是 62，所以下面需要读取 62 字节。 再下一行是 0000，表示服务端已完成了发送引用列表过程。

现在它知道了服务端的状态，你的 send-pack 进程会判断哪些提交记录是它所拥有但服务端没有的。send-pack 会告知 receive-pack 这次推送将会更新的各个引用。 举个例子，如果你正在更新 master 分支，并且增加 experiment 分支，这个 send-pack 的响应将会是像这样：

Git 会为每一个将要更新的引用发送一行数据，包括该行长度，旧 SHA-1 值，新 SHA-1 值和将要更新的引用。 第一行也包括了客户端的能力。 这里的全为 0 的 SHA-1 值表示之前没有过这个引用——因为你正要添加新的 experiment 引用。 删除引用时，将会看到相反的情况：右边的 SHA-1 值全为 0。

接下来，客户端会发送一个包文件，它包含了所有服务端还没有的对象。 最后，服务端会以成功（或失败）响应：

HTTPS 与 HTTP 相比较，除了在“握手”过程略有不同外，其他基本相似。 连接是从下面这个请求开始的：

这完成了客户端和服务端的第一次数据交换。 接下来客户端发起另一个请求，这次是一个 POST 请求，这个请求中包含了 git-upload-pack 提供的数据。

这个 POST 请求的内容是 send-pack 的输出和相应的包文件。 服务端在收到请求后相应地作出成功或失败的 HTTP 响应。

如果你通过 SSH 使用抓取功能，fetch-pack 会像这样运行：

在 fetch-pack 连接后，upload-pack 会返回类似下面的内容：

这与 receive-pack 的响应很相似，但是这里所包含的能力是不同的。 而且它还包含 HEAD 引用所指向内容（symref=HEAD:refs/heads/master），这样如果客户端执行的是克隆，它就会知道要检出什么。

这时候，fetch-pack 进程查看它自己所拥有的对象，并响应 “want” 和它需要的对象的 SHA-1 值。 它还会发送“have”和所有它已拥有的对象的 SHA-1 值。 在列表的最后，它还会发送“done”以通知 upload-pack 进程可以开始发送它所需对象的包文件：

抓取操作的握手需要两个 HTTP 请求。 第一个是向和哑协议中相同的端点发送 GET 请求：

这和通过 SSH 使用 git-upload-pack 是非常相似的，但是第二个数据交换则是一个单独的请求：

这个输出格式还是和前面一样的。 这个请求的响应包含了所需要的包文件，并指明成功或失败。