Git 中文参考（五）（5）https://developer.aliyun.com/article/1565849
有关特定文件的信息，存储在索引中。如果合并已启动但尚未完成（即，如果索引包含该文件的多个版本），则索引条目可以是未合并的。
master
默认开发分支。无论何时创建 Git 存储库，都会创建一个名为“master”的分支，并成为活动分支。在大多数情况下，这包含本地开发，虽然这纯粹是按照惯例而不是必需的。
merge
作为动词：将另一个分支（可能来自外部存储库）的内容带入当前分支。在合并分支来自不同存储库的情况下，这通过首先获取远程分支然后将结果合并到当前分支来完成。这种获取和合并操作的组合称为 pull 。合并由一个自动过程执行，该过程识别自分支分叉后所做的更改，然后将所有这些更改一起应用。如果更改发生冲突，则可能需要手动干预才能完成合并。
作为名词：除非它是快进，否则成功合并会导致创建表示合并结果的新提交，并具有父合并分支的提示。此提交称为“合并提交”，有时仅称为“合并”。
object
Git 中的存储单元。它由 SHA-1 的内容唯一标识。因此，不能改变对象。
object database
存储一组“对象”，单个对象由其对象名称标识。对象通常存在于$GIT_DIR/objects/中。
object identifier
对象名称的同义词。
object name
对象的唯一标识符。对象名称通常由 40 个字符的十六进制字符串表示。通俗地称为 SHA-1 。
object type
其中一个标识符“提交”，“树”，“标签”或“ blob ”描述 HTG8 的类型对象。
octopus
[合并超过两个分支。
origin
默认上游存储库。大多数项目至少有一个他们跟踪的上游项目。默认情况下 _ 原点 _ 用于此目的。新的上游更新将被提取到名为 origin / name-of-upstream-branch 的远程跟踪分支中，您可以使用git branch -r查看。
pack
已压缩到一个文件中的一组对象（以节省空间或有效传输它们）。
pack index
包中对象的标识符列表和其他信息，以帮助有效地访问包的内容。
pathspec
用于限制 Git 命令中的路径的模式。
Pathspecs 用于命令行“git ls-files”，“git ls-tree”，“git add”，“git grep”，“git diff”，“git checkout”以及许多其他命令以限制范围对树或工作树的某个子集的操作。有关路径是相对于当前目录还是顶层的信息，请参阅每个命令的文档。 pathspec 语法如下：
- 任何路径都匹配自己
- 最后一个斜杠的 pathspec 表示目录前缀。 pathpec 的范围仅限于该子树。
- 其余的 pathspec 是路径名的其余部分的模式。使用 fnmatch（3）将相对于目录前缀的路径与该模式匹配;特别是 * 和 ？ _ 可以 _ 匹配目录分隔符。
例如，Documentation / * .jpg 将匹配文档子树中的所有.jpg 文件，包括 Documentation / chapter_1 / figure_1.jpg。
以冒号:开头的 pathspec 具有特殊含义。在简短形式中，前导冒号:后跟零个或多个“魔术签名”字母（可选地由另一个冒号:终止），余数是与路径匹配的模式。 “魔术签名”由 ASCII 符号组成，既不是字母数字，也不是字母，正则表达式，也不是冒号。如果模式以不属于“魔术签名”符号集且不是冒号的字符开头，则可以省略终止“魔术签名”的可选冒号。
在长形式中，前导冒号:后面是一个左括号(，一个逗号分隔的零个或多个“魔术词”列表，以及一个括号)，其余的是与路径相匹配。
仅包含冒号的 pathspec 意味着“没有 pathspec”。此表单不应与其他 pathspec 结合使用。
top
即使从子目录中运行命令，魔术字top（魔术签名：/）也会使工作树的根模式匹配。
literal
模式中的通配符（如*或?）被视为文字字符。
icase
不区分大小写的匹配。
glob
Git 将模式视为适合 fnmatch（3）使用 FNM_PATHNAME 标志的 shell glob：模式中的通配符与路径名中的/不匹配。例如，“Documentation / * .html”匹配“Documentation / git.html”，但不匹配“Documentation / ppc / ppc.html”或“tools / perf / Documentation / perf.html”。
与完整路径名匹配的两个连续星号（“**”）可能具有特殊含义：
- 前导“
**”后跟斜杠表示在所有目录中匹配。例如，“**/foo”在任何地方匹配文件或目录“foo”，与模式“foo”相同。 “**/foo/bar”将文件或目录“bar”匹配在“foo”目录下的任何位置。 - 尾随“
/**”匹配内部的所有内容。例如，“abc/**”匹配目录“abc”内的所有文件，相对于.gitignore文件的位置，具有无限深度。 - 斜杠后跟两个连续的星号，然后斜杠匹配零个或多个目录。例如，“
a/**/b”匹配“a/b”，“a/x/b”，“a/x/y/b”等。 - 其他连续星号被视为无效。
Glob 魔法与文字魔法不相容。
attr
在attr:出现空格分隔的“属性要求”列表之后，必须满足所有这些要求才能将路径视为匹配;这是除了通常的非魔术 pathpec 模式匹配之外。见 gitattributes [5] 。
路径的每个属性要求都采用以下形式之一：
- “
ATTR”要求设置属性ATTR。 - “
-ATTR”要求取消设置ATTR属性。 - “
ATTR=VALUE”要求将属性ATTR设置为字符串VALUE。 - “
!ATTR”要求未指定属性ATTR。
请注意，在对树对象进行匹配时，仍然可以从工作树获取属性，而不是从给定的树对象获取属性。
exclude
在路径匹配任何非排除路径规范后，它将运行所有排除路径规范（魔术签名：!或其同义词^）。如果匹配，则忽略该路径。如果没有非排除路径规范，则将排除应用于结果集，就像在没有任何 pathspec 的情况下调用一样。
parent
提交对象包含开发线中的逻辑前任（即其父项）的（可能是空的）列表。
pickaxe
术语 pickaxe 是指 diffcore 例程的一个选项，它有助于选择添加或删除给定文本字符串的更改。使用--pickaxe-all选项，它可用于查看引入或删除的完整变更集，例如特定的文本行。参见 git-diff [1] 。
plumbing
核心 Git 的可爱名称。
porcelain
程序和程序套件的可爱名称取决于核心 Git ，提供对核心 Git 的高级访问。与管道相比，瓷器暴露出更多的 SCM 界面。
per-worktree ref
根据工作树的参考，而不是全局。目前只有 HEAD 以及以refs/bisect/开头的任何引用，但后来可能包括其他不寻常的引用。
pseudoref
Pseudorefs 是$GIT_DIR下的一类文件，其行为类似于 refs 用于 rev-parse，但是由 git 专门处理。伪数据都具有全大写的名称，并且始终以包含 SHA-1 后跟空格的行开头。因此，HEAD 不是伪目标，因为它有时是一个象征性的参考。它们可以选择包含一些其他数据。 MERGE_HEAD和CHERRY_PICK_HEAD是示例。与 per-worktree refs 不同，这些文件不能是符号引用，也不会有 reflog。它们也无法通过正常的 ref 更新机器进行更新。相反，它们通过直接写入文件来更新。但是，它们可以被读作好像是参考，因此git rev-parse MERGE_HEAD将起作用。
pull
拉分支意味着获取它和合并它。另见 git-pull [1] 。
push
推动分支意味着从远程存储库获取分支的头部参考，找出它是否是分支的本地头部参考的祖先，并且 case，将可以从本地 head ref 访问的对象和远程存储库中缺失的对象放入远程对象数据库，并更新远程头部 ref。如果远程头不是本地磁头的祖先，则推送失败。
reachable
给定提交的所有祖先都被认为是来自该提交的“可达”。更一般地说，一个对象可以从另一个到达，如果我们可以通过链跟随标签到达另一个到它们标记的任何东西，将提交给他们的父母或树木，将树提交给他们所包含的树木或 blob 。
rebase
要重新应用从分支到不同基数的一系列更改，并将该分支的头重置为结果。
ref
以refs/开头的名称（例如refs/heads/master）指向对象名称或另一个 ref（后者称为符号 ref ））。为方便起见，当用作 Git 命令的参数时，ref 有时可以缩写;有关详细信息，请参阅 gitrevisions [7] 。 Refs 存储在存储库中。
ref 命名空间是分层的。不同的子层次结构用于不同的目的（例如，refs/heads/层次结构用于表示本地分支）。
有一些特殊用途的参考不以refs/开头。最值得注意的例子是HEAD。
reflog
reflog 显示 ref 的本地“历史”。换句话说，它可以告诉你 _ 这个 _ 存储库中的第 3 个最后修订是什么，以及昨天晚上 9 点 14 分 _ 这个 _ 存储库中的当前状态是什么。有关详细信息，请参阅 git-reflog [1] 。
refspec
fetch 和 push 使用“refspec”来描述远程 ref 和本地 ref 之间的映射。
remote repository
存储库，用于跟踪同一个项目但位于其他地方。要与遥控器通信，请参阅获取或按。
remote-tracking branch
ref ，用于跟踪来自另一个存储库的更改。它通常看起来像 refs / remotes / foo / bar （表示它在名为 foo 的遥控器中跟踪一个名为 bar 的分支），并且匹配右边 - 已配置的提取 refspec 的手边。远程跟踪分支不应包含直接修改或对其进行本地提交。
repository
refs 的集合以及对象数据库，其中包含来自 refs 的可达的所有对象，可能伴随来自一个或多个瓷器的元数据。存储库可以通过交替机制与其他存储库共享对象数据库。
resolve
手动修复失败的自动合并留下的动作。
revision
commit （名词）的同义词。
rewind
抛弃部分开发，即将头分配给早期修订版。
SCM
源代码管理（工具）。
SHA-1
“安全哈希算法 1”;加密哈希函数。在 Git 的上下文中用作对象名称的同义词。
shallow clone
通常是浅存储库的同义词，但该短语使其更明确地表示它是通过运行git clone --depth=...命令创建的。
shallow repository
一个浅存储库有一个不完整的历史，其中一些提交有父母烧灼（换句话说，Git 被告知假装这些提交没有父母，即使他们被记录在提交对象中）。当您仅对项目的近期历史感兴趣时，这有时很有用，即使上游记录的真实历史要大得多。通过向 git-clone [1] 提供--depth选项来创建浅存储库，并且可以稍后使用 git-fetch [1] 加深其历史记录。
stash entry
对象用于临时存储脏工作目录的内容和索引以供将来重用。
submodule
存储库，用于保存另一个存储库中的单独项目的历史记录（后者称为 superproject ）。
superproject
存储库，它将工作树中其他项目的存储库作为子模块引用。超级项目知道所包含的子模块的提交对象的名称（但不包含其副本）。
symref
符号引用：它不是包含 SHA-1 id 本身，而是格式为 ref：refs / some / thing ，并且在引用时，它递归地取消引用此引用。 _HEAD _ 是 symref 的主要示例。使用 git-symbolic-ref [1] 命令操纵符号引用。
tag
refs/tags/命名空间下的 ref 指向任意类型的对象（通常标签指向标签或提交对象）。与头相反，commit命令不会更新标签。 Git 标签与 Lisp 标签无关（在 Git 的上下文中称为对象类型）。标记最常用于标记提交祖先链中的特定点。
tag object
包含 ref 的对象指向另一个对象，该对象可以包含类似提交对象的消息。它还可以包含（PGP）签名，在这种情况下，它被称为“签名标记对象”。
topic branch
一个常规的 Git 分支，开发人员用它来识别概念的开发线。由于分支非常容易且便宜，因此通常需要具有若干小分支，每个小分支包含非常明确定义的概念或小的增量但相关的变化。
tree
工作树或树对象与从属 blob 和树对象（即工作树的存储表示）一起。
tree object
包含文件名和模式列表的对象以及对关联的 blob 和/或树对象的引用。 树相当于目录。
tree-ish (also treeish)
树对象或对象，可以递归地解除引用到树对象。解除引用提交对象产生对应于修订版的顶部目录的树对象。以下是所有树形图： commit-ish ，树对象，指向树对象的标记对象，指向指向标记对象的标记对象到树对象等
unmerged index
索引包含未合并的索引条目。
unreachable object
来自分支，标签或任何其他参考的对象不是可到达的。
upstream branch
合并到相关分支中的默认分支（或者有问题的分支被重新分配到）。它通过分支配置。< name> .remote 和 branch。< name> .merge。如果 A 的上游分支是 _ 起源/ B_ ，有时我们说“ A 正在追踪 _ 起源/ B_ ”。
working tree
实际签出文件的树。工作树通常包含 HEAD 提交树的内容，以及您已经进行但尚未提交的任何本地更改。
也可以看看
gittutorial [7] ， gittutorial-2 [7] ， gitcvs-migration [7] ， giteveryday [7] ， Git 用户手册
GIT
部分 git [1] 套件
githooks
名称
githooks - Git 使用的钩子
概要
$ GIT_DIR / hooks / *（或git config core.hooksPath / *）
描述
钩子是可以放在钩子目录中的程序，用于在 git 的执行中的某些点触发动作。没有设置可执行位的挂钩将被忽略。
默认情况下，hooks 目录为$GIT_DIR/hooks，但可以通过core.hooksPath配置变量进行更改（参见 git-config [1] ）。
在 Git 调用钩子之前，它将其工作目录更改为裸存储库中的$ GIT_DIR 或非裸存储库中工作树的根。推送期间触发的挂钩例外（_ 预接收 ， 更新 ， 接收后 ， 更新后 _， push-to-checkout ）总是在$ GIT_DIR 中执行。
钩子可以通过环境，命令行参数和 stdin 获取它们的参数。有关详细信息，请参阅下面每个挂钩的文档。
git init可能会将挂钩复制到新存储库，具体取决于其配置。有关详细信息，请参见 git-init [1] 中的“TEMPLATE DIRECTORY”部分。当本文档的其余部分引用“默认挂钩”时，它正在讨论 Git 附带的默认模板。
目前支持的钩子如下所述。
挂钩
applypatch-MSG
这个钩子由 git-am [1] 调用。它需要一个参数，即包含建议的提交日志消息的文件的名称。退出非零状态会导致git am在应用修补程序之前中止。
允许钩子编辑消息文件，并可用于将消息规范化为某种项目标准格式。它还可以用于在检查消息文件后拒绝提交。
默认 applypatch-msg 挂钩，如果启用，则运行 commit-msg 挂钩，如果后者启用的话。
预 applypatch
这个钩子由 git-am [1] 调用。它不需要参数，并且在应用补丁之后但在提交之前调用。
如果它以非零状态退出，则在应用补丁后将不会提交工作树。
它可用于检查当前工作树，如果未通过某些测试则拒绝提交。
默认的 pre-applypatch 挂钩启用时会运行 _ 预提交 _ 挂钩，如果后者启用的话。
后 applypatch
这个钩子由 git-am [1] 调用。它不需要参数，并在应用补丁并进行提交后调用。
此挂钩主要用于通知，不会影响git am的结果。
预提交
这个钩子由 git-commit [1] 调用，可以用--no-verify选项旁路。它不需要任何参数，并在获取建议的提交日志消息和进行提交之前调用。退出此脚本的非零状态会导致git commit命令在创建提交之前中止。
默认的 _ 预提交 _ 挂钩，在启用时，会捕获带有尾随空格的行的引入，并在找到这样的行时中止提交。
如果命令不会调出编辑器来修改提交消息，则使用环境变量GIT_EDITOR=:调用所有git commit挂钩。
准备提交-MSG
在准备默认日志消息之后，在编辑器启动之前， git-commit [1] 会调用此挂钩。
它需要一到三个参数。第一个是包含提交日志消息的文件的名称。第二个是提交消息的来源，可以是：message（如果给出了-m或-F选项）; template（如果给出了-t选项或设置了配置选项commit.template）; merge（如果提交是合并或.git/MERGE_MSG文件存在）; squash（如果存在.git/SQUASH_MSG文件）;或commit，然后是提交 SHA-1（如果给出了-c，-C或--amend选项）。
如果退出状态为非零，则git commit将中止。
挂钩的目的是在适当的位置编辑消息文件，并且不会被--no-verify选项抑制。非零退出意味着挂钩失败并中止提交。它不应该用作预提交钩子的替代品。
Git 附带的示例prepare-commit-msg挂钩删除了在提交模板的注释部分中找到的帮助消息。
提交-MSG
这个钩子由 git-commit [1] 和 git-merge [1] 调用，可以用--no-verify选项绕过。它需要一个参数，即包含建议的提交日志消息的文件的名称。以非零状态退出会导致命令中止。
允许钩子编辑消息文件，并可用于将消息规范化为某种项目标准格式。它还可以用于在检查消息文件后拒绝提交。
默认的 commit-msg 挂钩启用时会检测到重复的“Signed-off-by”行，如果找到，则中止提交。
提交后
这个钩子由 git-commit [1] 调用。它不需要参数，并在提交后调用。
此挂钩主要用于通知，不会影响git commit的结果。
前底垫
这个钩子由 git-rebase [1] 调用，可以用来防止分支被重新绑定。可以用一个或两个参数调用钩子。第一个参数是分支系列的上游。第二个参数是重新分支的分支，在重新定位当前分支时不会设置。
后检出
更新工作树后运行 git-checkout [1] 时会调用此挂钩。钩子被赋予三个参数：前一个 HEAD 的 ref，新 HEAD 的 ref（可能已经或可能没有改变），以及一个标志，指示检出是否是分支检出（更改分支，标志= 1）或文件签出（从索引中检索文件，标志= 0）。这个钩子不会影响git checkout的结果。
它也在 git-clone [1] 之后运行，除非使用--no-checkout（-n）选项。给钩子的第一个参数是 null-ref，第二个是新 HEAD 的 ref，而标志总是 1.同样对于git worktree add，除非使用--no-checkout。
此挂钩可用于执行存储库有效性检查，如果不同则自动显示与先前 HEAD 的差异，或设置工作目录元数据属性。
后合并
这个钩子由 git-merge [1] 调用，当在本地存储库上完成git pull时会发生这种情况。钩子接受一个参数，一个状态标志，指定合并是否是一个压缩合并。如果由于冲突导致合并失败，则此挂钩不会影响git merge的结果，也不会执行。
该钩子可以与相应的预提交钩子一起使用，以保存和恢复与工作树相关联的任何形式的元数据（例如：权限/所有权，ACLS 等）。有关如何执行此操作的示例，请参阅 contrib / hooks / setgitperms.perl。
前推
这个钩子由 git-push [1] 调用，可用于防止发生推动。使用两个参数调用钩子，这两个参数提供目标远程的名称和位置，如果未使用命名远程，则两个值将相同。
有关要推送内容的信息在钩子的标准输入上提供了以下形式的行：
<local ref> SP <local sha1> SP <remote ref> SP <remote sha1> LF
例如，如果运行命令git push origin master:foreign，则挂钩将收到如下所示的行：
refs/heads/master 67890 refs/heads/foreign 12345
虽然将提供完整的 40 个字符的 SHA-1。如果外来参考不存在，将为 40 0。如果要删除 ref，将作为(delete)提供，将为 40 0。如果本地提交是由可以扩展的名称以外的其他东西指定的（例如HEAD~或 SHA-1），它将按照最初给出的方式提供。
如果此挂钩以非零状态退出，则git push将在不推送任何内容的情况下中止。可以通过写入标准错误将关于推送拒绝原因的信息发送给用户。
预接收
当 git-receive-pack [1] 对git push作出反应并更新其存储库中的引用时，将调用此挂钩。在开始更新远程存储库上的 refs 之前，将调用预接收挂钩。其退出状态决定了更新的成功或失败。
该钩子为接收操作执行一次。它不需要参数，但是对于每个 ref 都要更新它在标准输入上接收格式的一行：
<old-value> SP <new-value> SP <ref-name> LF
其中是存储在 ref 中的旧对象名称，是要存储在 ref 中的新对象名称，是 ref 的全名。创建新参考时，为 40 0。
如果钩子以非零状态退出，则不会更新任何引用。如果钩子退出零，则 _ 更新 _ 钩子仍然可以防止更新单个引用。
标准输出和标准错误输出都转发到另一端的git send-pack，因此您只需为用户输入echo消息即可。
在git push --push-option=...的命令行上给出的推送选项的数量可以从环境变量GIT_PUSH_OPTION_COUNT中读取，选项本身可以在GIT_PUSH_OPTION_0，GIT_PUSH_OPTION_1中找到，…如果协商不使用推送选项阶段，不会设置环境变量。如果客户端选择使用推送选项但不传输任何选项，则计数变量将设置为零，GIT_PUSH_OPTION_COUNT=0。
有关注意事项，请参阅 git-receive-pack [1] 中的“隔离环境”部分。
更新
当 git-receive-pack [1] 对git push作出反应并更新其存储库中的引用时，将调用此挂钩。在更新远程存储库上的 ref 之前，将调用更新挂钩。其退出状态决定了 ref 更新的成功或失败。
钩子为每个 ref 更新执行一次，并带有三个参数：
- 要更新的 ref 的名称，
- 存储在 ref 中的旧对象名称，
- 以及要存储在 ref 中的新对象名称。
从更新挂钩零退出允许更新 ref。以非零状态退出会阻止git receive-pack更新该 ref。
此挂钩可用于通过确保对象名称是提交对象来防止 _ 强制 _ 更新某些引用，该提交对象是旧对象名称所指定的提交对象的后代。也就是说，执行“仅限快进”政策。
它还可以用于记录 old…new 状态。但是，它并不知道整个分支集合，所以当天真地使用时，它最终会为每个 ref 发送一封电子邮件。 _ 接收后 _ 钩子更适合这种情况。
在限制用户仅通过线路访问 git 命令的环境中，此挂钩可用于实现访问控制，而不依赖于文件系统所有权和组成员身份。请参阅 git-shell [1] ，了解如何使用登录 shell 限制用户只能访问 git 命令。
标准输出和标准错误输出都转发到另一端的git send-pack，因此您只需为用户输入echo消息即可。
默认 _ 更新 _ 挂钩，启用时 - hooks.allowunannotated配置选项未设置或设置为 false-可防止未注释的标签被推送。
后收到
当 git-receive-pack [1] 对git push作出反应并更新其存储库中的引用时，将调用此挂钩。在更新所有引用后，它将在远程存储库上执行一次。
该钩子为接收操作执行一次。它不需要参数，但获得的信息与 _ 预接收 _ 钩子在其标准输入上的信息相同。
这个钩子不会影响git receive-pack的结果，因为它是在完成实际工作后调用的。
这取代了 _ 更新后 _ 钩子，除了它们的名称之外，它还获得了所有引用的旧值和新值。
标准输出和标准错误输出都转发到另一端的git send-pack，因此您只需为用户输入echo消息即可。
默认的 post-receive 挂钩是空的，但是在 Git 发行版的contrib/hooks目录中提供了一个示例脚本post-receive-email，它实现了发送提交电子邮件。
在git push --push-option=...的命令行上给出的推送选项的数量可以从环境变量GIT_PUSH_OPTION_COUNT中读取，选项本身可以在GIT_PUSH_OPTION_0，GIT_PUSH_OPTION_1中找到，…如果协商不使用推送选项阶段，不会设置环境变量。如果客户端选择使用推送选项但不传输任何选项，则计数变量将设置为零，GIT_PUSH_OPTION_COUNT=0。
更新后的
当 git-receive-pack [1] 对git push作出反应并更新其存储库中的引用时，将调用此挂钩。在更新所有引用后，它将在远程存储库上执行一次。
它需要可变数量的参数，每个参数都是实际更新的 ref 的名称。
此挂钩主要用于通知，不会影响git receive-pack的结果。
_ 更新后 _ 挂钩可以判断推送的磁头是什么，但是它不知道它们的原始值和更新值是什么，因此它是一个糟糕的做旧日志的地方。 _ 接收后 _ 钩子确实获得了 refs 的原始值和更新值。如果你需要它们，你可以考虑它。
启用后，默认 _ 更新后 _ 挂钩运行git update-server-info，以使哑传输（例如 HTTP）使用的信息保持最新。如果要发布可通过 HTTP 访问的 Git 存储库，则应该启用此挂钩。
标准输出和标准错误输出都转发到另一端的git send-pack，因此您只需为用户输入echo消息即可。
一键检出
当 git-receive-pack [1] 对git push做出反应并更新其存储库中的引用时，以及当 push 尝试更新当前已检出的分支时，将调用此挂钩并且receive.denyCurrentBranch配置变量设置为updateInstead。如果工作树和远程存储库的索引与当前检出的提交有任何差异，则默认拒绝这样的推送;当工作树和索引都与当前提交匹配时，它们会更新以匹配新推送的分支提示。此挂钩用于覆盖默认行为。
钩子接收提交，当前分支的尖端将被更新。它可以以非零状态退出以拒绝推送（当它这样做时，它不能修改索引或工作树）。或者它可以对工作树和索引进行任何必要的更改，以便在当前分支的提示更新为新提交时将它们置于所需状态，并以零状态退出。
例如，钩子可以简单地运行git read-tree -u -m HEAD "$1"以模拟git push与git push反向运行的git fetch，因为git read-tree -u -m的双树形式与切换的git checkout基本相同分支，同时保持工作树中的本地更改不会干扰分支之间的差异。
预自动 GC
该钩子由git gc --auto调用（参见 git-gc [1] ）。它不带参数，从此脚本退出非零状态会导致git gc --auto中止。
后重写
这个钩子由重写提交的命令调用（ git-commit [1] 用--amend和 git-rebase [1] 调用;当前git filter-branch执行 _ 不是 _ 打电话给它！）。它的第一个参数表示它被调用的命令：当前amend或rebase之一。将来可能会传递更多与命令相关的参数。
钩子以格式接收 stdin 上重写提交的列表
<old-sha1> SP <new-sha1> [ SP <extra-info> ] LF
extra-info 再次依赖于命令。如果为空，则也省略前面的 SP。目前，没有命令传递任何 extra-info 。
自动注释复制后，钩子总是运行（参见 git-config [1] 中的“notes.rewrite。< command>”），因此可以访问这些注释。
以下特定于命令的注释适用：
rebase
对于 _ 壁球 _ 和 fixup 操作，所有被压缩的提交都被列为被重写为压缩的提交。这意味着将有几行共享相同的 new-sha1 。
保证提交按照 rebase 处理它们的顺序列出。
sendemail-验证
这个钩子由 git-send-email [1] 调用。它需要一个参数，即保存要发送的电子邮件的文件的名称。退出非零状态会导致git send-email在发送任何电子邮件之前中止。
fsmonitor 守卫员
当配置选项core.fsmonitor设置为.git/hooks/fsmonitor-watchman时，将调用此挂钩。它需要两个参数，一个版本（当前为 1）和自 1970 年 1 月 1 日午夜以来经过的纳秒时间。
钩子应输出到 stdout 工作目录中可能自请求的时间以来可能已更改的所有文件的列表。逻辑应该具有包容性，以便它不会错过任何潜在的变化。路径应该相对于工作目录的根目录，并由单个 NUL 分隔。
可以包含实际没有更改的文件。应包括所有更改，包括新创建和删除的文件。重命名文件时，应包括旧名称和新名称。
Git 将限制检查更改的文件以及根据给定的路径名检查未跟踪文件的目录。
告诉 git“所有文件都已更改”的优化方法是返回文件名/。
退出状态确定 git 是否将使用钩子中的数据来限制其搜索。出错时，它将回退到验证所有文件和文件夹。
P4-预提交
该钩子由git-p4 submit调用。它不需要参数，也不需要标准输入。从此脚本退出非零状态会阻止git-p4 submit启动。运行git-p4 submit --help了解详细信息。
GIT
部分 git [1] 套件
Git 中文参考（五）（7）https://developer.aliyun.com/article/1565851
