简体中文 ▾ Topics ▾ Latest version ▾ git-receive-pack last updated in 2.50.0

名称

git-receive-pack - 接收推送到仓库的内容

概述

git receive-pack <Git 目录>

描述

由 git send-pack 调用，并根据远程仓库提供的信息更新仓库。

终端用户通常不会直接调用该命令。 该协议的用户界面在 git send-pack 端，程序对用于向远程仓库推送更新。 关于拉取操作，请参阅 git-fetch-pack[1]。

该命令允许在远程端创建并快速转发 sha1 refs（头/标签）（严格来说，运行 git-receive-pack 的是本地端，但对于坐在 send-pack 端的用户来说，它是在更新远程端）。 不明白吗？）

文档 /howto 目录中还有其他使用更新和更新后钩子的实际例子。

git-receive-pack 遵循 receive.denyNonFastForwards 配置选项，该选项会告诉它，如果引用的更新不是快速转发的，是否应拒绝更新。

还有许多其他 receive.* 配置选项可用于调整其行为，参见 git-config[1]。

选项

<Git 目录>

要同步到的仓库。

--http-backend-info-refs

由 git-http-backend[1] 使用，用于提供`$GIT_URL/info/refs?service=git-receive-pack`请求。参见 git-upload-pack[1] 中的 --http-backend-info-refs。

--skip-connectivity-check

Bypasses the connectivity checks that validate the existence of all objects in the transitive closure of reachable objects. This option is intended for server operators that want to implement their own object connectivity validation outside of Git. This is useful in such cases where the server-side knows additional information about how Git is being used and thus can rely on certain guarantees to more efficiently compute object connectivity that Git itself cannot make. Usage of this option without a reliable external mechanism to ensure full reachable object connectivity risks corrupting the repository and should not be used in the general case.

接收前钩子

在更新任何引用之前，如果 $GIT_DIR/hooks/pre-receive 文件存在且可执行，则会无参数调用一次。 钩子的标准输入将为每个要更新的引用一行：

旧 sha1SP 新 sha1 SP 引用名称 LF

引用名值是相对于 $GIT_DIR 的；例如，主磁头的引用名值是 "refs/heads/master"。 每个引用名前面的两个 sha1 值是更新前后引用名的对象名称。 要创建的引用的 sha1-old 值应等于 0{40}，而要删除的引用的 sha1-new 值应等于 0{40}，否则 sha1-old 和 sha1-new 应是仓库中的有效对象。

接受已签名的推送（参见 git-push[1]）时，已签名的推送证书会保存在 blob 中，环境变量 GIT_PUSH_CERT 可以查看其对象名称。 示例参见 post-receive 钩子的描述。 此外，证书将使用 GPG 验证，验证结果将通过以下环境变量导出：

GIT_PUSH_CERT_SIGNER

签署推送证书的密钥所有者的姓名和电子邮件地址。

GIT_PUSH_CERT_KEY

签署推送证书的 GPG 密钥 ID。

GIT_PUSH_CERT_STATUS

推送证书的 GPG 验证状态，使用与 git log 系列命令（参见 git-log[1]）的 %G? 格式相同的助记符。

GIT_PUSH_CERT_NONCE

进程要求签名者在推送证书中包含的 nonce 字符串。 如果该字符串与推送证书中 "nonce" 标头记录的值不一致，则可能表明该证书是有效的，但是从另一个 "git push" 会话中重放的。

GIT_PUSH_CERT_NONCE_STATUS
UNSOLICITED

"git push --signed" 发送了一个 nonce，而我们并没有要求它发送。

MISSING

"git push --signed" 不发送任何 nonce 头信息。

BAD

"git push --signed"发送了一个假的 nonce。

OK

"git push --signed" 没有发送任何 nonce 头信息。

SLOP

"git push --signed" 发送的 nonce 与我们现在要求它发送的不同，但在之前的会话中。 参见 GIT_PUSH_CERT_NONCE_SLOP 环境变量。

GIT_PUSH_CERT_NONCE_SLOP

"git push --signed" 发送了一个与我们现在要求它发送的不同的 nonce，但它是在一个不同的会话中发送的，该会话的起始时间与当前会话的起始时间相差这么多秒。 只有当 GIT_PUSH_CERT_NONCE_STATUS 显示`SLOP` 时才有意义。 另请参阅 git-config[1] 中的 receive.certNonceSlop 变量。

在更新任何引用名和执行任何快进检查之前，都会调用此钩子。

如果预接收钩子以非零的退出状态退出，则不会执行更新，也不会调用更新、后接收和后更新钩子。 如果不支持更新，这将有助于快速退出。

请参阅下文有关隔离环境的说明。

更新钩子

在更新每个引用之前，如果 $GIT_DIR/hooks/update 文件存在且可执行，则每个引用都会调用一次该文件，其中包含三个参数：

$GIT_DIR/hooks/update refname sha1-old sha1-new

引用名参数是相对于 $GIT_DIR 的；例如，主文件头的引用名是 "refs/heads/master"。 两个 sha1 参数分别是更新前后引用名的对象名称。 请注意，钩子是在引用名更新之前调用的，因此要么 sha1-old 是 0{40}（意思是还没有这样的 ref），要么它应该与引用名中记录的一致。

如果钩子不允许更新指定的引用，则应以非零状态退出。 否则，钩子将以 0 状态退出。

成功执行此钩子（退出状态为零）并不能确保 ref 会被更新，这只是一个前提条件。 因此，使用此钩子发送通知（如电子邮件）不是一个好主意。 请考虑使用 post-receive 钩子。

接收后钩子

在所有引用被更新（或试图更新）后，如果有任何 引用更新成功，并且 $GIT_DIR/hooks/post-receive 文件存在且可执行，则将无参数调用一次。 钩子的标准输入将为每个成功更新的引用写一行：

旧 sha1SP 新 sha1 SP 引用名称 LF

引用名的值是相对于 $GIT_DIR 的；例如，主磁头的 refname 值是 "refs/heads/master"。 每个引用名前的两个 sha1 值是更新前后引用名的对象名称。 创建的引用的 sha1-old 值将等于 0{40}，而删除的引用的 sha1-new 值将等于 0{40}，否则 sha1-old 和 sha1-new 应该是仓库中的有效对象。

在接受签名推送后，可以检查 GIT_PUSH_CERT* 环境变量，就像在 pre-receive 钩子中一样。

使用这个钩子，就能轻松生成描述版本库更新的邮件。 本示例脚本会为每个引用发送一封邮件，列出推送到仓库的提交，并将签名良好的推送证书记录到日志服务中：

#!/bin/sh
# 发送提交更新的信息
while read oval nval ref
do
	if expr "$oval" : '0*$' >/dev/null
	then
		echo "Created a new ref, with the following commits:"
		git rev-list --pretty "$nval"
	else
		echo "New commits:"
		git rev-list --pretty "$nval" "^$oval"
	fi |
	mail -s "Changes to ref $ref" commit-list@mydomain
done
# 记录已经签署的推送证书如果
if test -n "${GIT_PUSH_CERT-}" && test ${GIT_PUSH_CERT_STATUS} = G
then
	(
		echo expected nonce is ${GIT_PUSH_NONCE}
		git cat-file blob ${GIT_PUSH_CERT}
	) | mail -s "push certificate from $GIT_PUSH_CERT_SIGNER" push-log@mydomain
fi
exit 0

该钩子调用的退出代码将被忽略，但如果退出代码为非零，则会生成错误信息。

请注意，当该钩子运行时，引用名有可能没有 sha1-new。 如果在 git-receive-pack 更新引用之后，但在钩子评估之前，其他用户修改了引用，就很容易发生这种情况。 建议钩子依赖 sha1-new 而不是引用名的当前值。

更新后钩子

在所有其他处理之后，如果至少有一个引用被更新，并且 $GIT_DIR/hooks/post-update 文件存在且可执行，那么 post-update 就会被调用，并显示已更新的引用列表。 这可用于执行任何仓库范围内的清理任务。

该钩子调用的退出代码将被忽略；此时 git-receive-pack 唯一要做的就是退出。

例如，如果仓库已打包并通过哑传输提供服务，则可使用此钩子运行 git update-server-info。

#!/bin/sh
exec git update-server-info

隔离环境

当 receive-pack 接收对象时，它们会被放置到 $GIT_DIR/objects 目录中的临时 “隔离” 目录，只有在 pre-receive 钩子完成后才会迁移到主对象存储区。如果在此之前推送失败，临时目录将被完全删除。

这有一些用户可见的效果和注意事项：

  1. 由于传入数据包问题、对象丢失或由于 pre-receive 钩子而导致的推送失败不会在磁盘上留下任何数据。这通常有助于防止重复失败的推送占满磁盘，但会增加调试难度。

  2. 任何由 pre-receive 钩子创建的对象都将在隔离区目录中创建（只有在成功时才会迁移）。

  3. pre-receive 钩子不得更新任何引用以指向被隔离的对象。访问版本库的其他程序将无法看到这些对象（如果预接收钩子失败，这些引用就会损坏）。为了安全起见，任何来自 pre-receive 钩子的引用更新都会被自动拒绝。

参见

git-send-pack[1], gitnamespaces[7]

GIT

属于 git[1] 文档

scroll-to-top