git-receive-pack - 云端在线

程序：

您的姓名

git-receive-pack - 接收推送到存储库中的内容

概要

git-接收包

商品描述

调用者 混帐 发送包 并使用从提供的信息更新存储库
远端。

此命令通常不会由最终用户直接调用。 协议的 UI 是
在 混帐 发送包 侧，并且程序对旨在用于将更新推送到
远程存储库。 有关拉取操作，请参阅 git-fetch 包（1）。

该命令允许在
远程端（严格来说，是本地端 git-接收包 运行，但对用户
谁坐在发送包端，它正在更新遥控器。 使困惑？）

还有其他使用更新和更新后挂钩的实际示例，请参见
文档/howto 目录。

git-接收包 尊重 receive.denyNonFastForwards 配置选项，它告诉它是否
如果不是快进，则应拒绝对 ref 的更新。

配置

要同步到的存储库。

预收 HOOK

在更新任何 ref 之前，如果 $GIT_DIR/hooks/pre-receive 文件存在并且是可执行的，它
将不带参数调用一次。 钩子的标准输入将是一行
每个要更新的参考：

sha1-旧 SP sha1-新 SP 引用名称 LF

refname 值是相对于 $GIT_DIR 的； 例如对于主头，这是
“裁判/负责人/大师”。 每个 refname 之前的两个 sha1 值是
refname 更新前后。 要创建的引用将具有 sha1-old 等于 0{40}，
而要删除的引用的 sha1-new 将等于 0{40}，否则 sha1-old 和
sha1-new 应该是存储库中的有效对象。

接受签名推送时（请参阅 混帐推送(1))，签名的推送证书存储在一个
blob 和环境变量 GIT_PUSH_CERT 可以查询其对象名称。 看
以 post-receive hook 的描述为例。 此外，证书是
使用 GPG 验证，结果使用以下环境变量导出：

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

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

GIT_PUSH_CERT_STATUS
推送证书的GPG验证状态，使用相同的助记符
在 %G 中使用？ git log 命令系列的格式（请参阅 混帐日志（1））。

GIT_PUSH_CERT_NONCE
进程要求签名者包含在推送证书中的随机数字符串。 如果
这与推送证书中“nonce”标头上记录的值不匹配，
它可能表明该证书是一个有效的，正在从
单独的“git push”会话。

GIT_PUSH_CERT_NONCE_STATUS

不请自来
当我们没有要求它发送一个随机数时，“git push --signed”发送了一个随机数。

失踪
“git push --signed”没有发送任何随机数标头。

差
“git push --signed”发送了一个虚假的随机数。

OK
“git push --signed”发送了我们要求它发送的随机数。

斜率
“git push --signed”发送的随机数与我们现在要求它发送的不同，但是
在上一届会议中。 请参阅 GIT_PUSH_CERT_NONCE_SLOP 环境变量。

GIT_PUSH_CERT_NONCE_SLOP
“git push --signed”发送的随机数与我们现在要求它发送的不同，但在一个
不同的会话，其开始时间与
当前会话。 仅当 GIT_PUSH_CERT_NONCE_STATUS 表示 SLOP 时才有意义。 还阅读
关于receive.certNonceSlop中的变量 混帐配置（1）。

在更新任何 refname 和任何快进检查之前调用此钩子
执行。

如果 pre-receive 钩子以非零退出状态退出，则不会执行更新，
并且 update、post-receive 和 post-update 钩子也不会被调用。 这可以
如果不支持更新，可以快速退出。

更新 HOOK

在每个 ref 更新之前，如果 $GIT_DIR/hooks/update 文件存在且可执行，则为
每个 ref 调用一次，带有三个参数：

$GIT_DIR/hooks/update refname sha1-旧 sha1-新

refname 参数是相对于 $GIT_DIR 的； 例如对于主头，这是
“裁判/负责人/大师”。 两个 sha1 参数是之前的 refname 的对象名称
和更新后。 请注意，在更新 refname 之前调用了钩子，因此
sha1-old 要么是 0{40}（意味着还没有这样的 ref），或者它应该匹配什么
记录在 refname 中。

如果钩子想禁止更新命名引用，它应该以非零状态退出。
否则它应该以零退出。

此钩子的成功执行（零退出状态）并不能确保 ref
其实要更新，那只是一个前提。 因此，发送不是一个好主意
来自这个钩子的通知（例如电子邮件）。 考虑使用 post-receive hook。

接收后 HOOK

在所有 ref 更新（或尝试更新）之后，如果有任何 ref 更新
成功，如果 $GIT_DIR/hooks/post-receive 文件存在并且是可执行的，它将是
不带参数调用一次。 钩子的标准输入将为每个
成功更新参考：

sha1-旧 SP sha1-新 SP 引用名称 LF

refname 值是相对于 $GIT_DIR 的； 例如对于主头，这是
“裁判/负责人/大师”。 每个 refname 之前的两个 sha1 值是
refname 更新前后。 创建的引用将具有 sha1-old 等于
0{40}，而被删除的引用的 sha1-new 将等于 0{40}，否则 sha1-old
并且 sha1-new 应该是存储库中的有效对象。

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

使用这个钩子，可以很容易地生成描述存储库更新的邮件。
此示例脚本为每个 ref 发送一封邮件消息，列出推送到
存储库，并将具有良好签名的已签名推送的推送证书记录到
记录器服务：

#!/ bin / sh的
# 邮寄提交更新信息。
读取椭圆形 nval 引用时
do
如果 expr "$oval" : '0*$' >/dev/null
然后
echo "创建了一个新的 ref，提交如下："
git rev-list --pretty "$nval"
其他
echo "新提交："
git rev-list --pretty "$nval" "^$oval"
菲 |
mail -s "更改引用 $ref" commit-list@mydomain
完成
# 记录签名的推送证书，如果有的话
if test -n "${GIT_PUSH_CERT-}" && test ${GIT_PUSH_CERT_STATUS} = G
然后
(
echo 预期随机数为 ${GIT_PUSH_NONCE}
git 猫文件 blob ${GIT_PUSH_CERT}
) | mail -s "从 $GIT_PUSH_CERT_SIGNER 推送证书" push-log@mydomain
fi
退出0

此挂钩调用的退出代码将被忽略，但非零退出代码将
生成错误消息。

请注意，当此挂钩运行时，refname 可能没有 sha1-new。 这个可以
如果其他用户在更新后修改引用，则很容易发生 git-接收包,
但在钩子能够评估它之前。 建议hooks依赖sha1-new
而不是 refname 的当前值。

更新后 HOOK

在所有其他处理之后，如果至少更新了一个 ref，并且
$GIT_DIR/hooks/post-update 文件存在且可执行，然后将调用 post-update
带有已更新的参考列表。 这可用于实现任何存储库
广泛的清理任务。

忽略此钩子调用的退出代码； 唯一剩下的
git-接收包 那时要做的就是退出自己。

例如，如果存储库是，则可以使用此挂钩运行 git update-server-info
包装并通过笨拙的运输服务。

#!/ bin / sh的
执行 git 更新服务器信息

使用 onworks.net 服务在线使用 git-receive-pack