# gitglossary > 原文： [https://git-scm.com/docs/gitglossary](https://git-scm.com/docs/gitglossary) ## 名称 gitglossary - Git词汇表 ## 概要 * ## 描述 ``` alternate object database ``` 通过交替机制，[存储库](#def_repository)可以从另一个对象数据库（称为“备用”）继承其[对象数据库](#def_object_database)的一部分。 ``` bare repository ``` 裸存储库通常是具有`.git`后缀的适当命名的[目录](#def_directory)，该后缀没有在版本控制下的任何文件的本地检出副本。也就是说，隐藏的`.git`子目录中通常存在的所有Git管理和控制文件都直接存在于`repository.git`目录中，并且没有其他文件存在并检出。通常，公共存储库的发布者可以使用裸存储库。 ``` blob object ``` 未输入的[对象](#def_object)，例如文件的内容。 ``` branch ``` “分支”是一个积极的发展路线。分支上最近的[提交](#def_commit)被称为该分支的提示。分支的尖端由分支[头](#def_head)引用，其在分支上进行额外的开发时向前移动。单个Git [存储库](#def_repository)可以跟踪任意数量的分支，但您的[工作树](#def_working_tree)只与其中一个（“当前”或“已检出”分支）相关联， [HEAD](#def_HEAD) 指向那个分支。 ``` cache ``` 已废弃：[索引](#def_index)。 ``` chain ``` 一个对象列表，其中列表中的每个[对象](#def_object)包含对其后继者的引用（例如，[提交](#def_commit)的后继者可能是其[父母之一](#def_parent) ）。 ``` changeset ``` BitKeeper / cvsps代表“ [commit](#def_commit) ”。由于Git不存储更改，但是状态，因此在Git中使用术语“changesets”实际上没有意义。 ``` checkout ``` 用来自[对象数据库](#def_object_database)的[树对象](#def_tree_object)或 [blob](#def_blob_object) 更新全部或部分[工作树](#def_working_tree)的动作，并更新[索引](#def_index)和 [HEAD](#def_HEAD) 如果整个工作树已指向新的[分支](#def_branch)。 ``` cherry-picking ``` 在 [SCM](#def_SCM) 行话中，“樱桃选择”意味着从一系列更改（通常是提交）中选择更改的子集，并将它们记录为在不同代码库之上的一系列新更改。在Git中，这是通过“git cherry-pick”命令执行的，以提取现有[提交](#def_commit)引入的更改，并根据当前[分支](#def_branch)的提示将其记录为新提交。 ``` clean ``` [工作树](#def_working_tree)是干净的，如果它对应于当前[头](#def_head)引用的[修订版](#def_revision)。另见“[脏](#def_dirty)”。 ``` commit ``` 作为名词：Git历史中的一个点;项目的整个历史记录表示为一组相互关联的提交。 Git通常在相同位置使用“commit”一词，其他版本控制系统使用“revision”或“version”。也用作[提交对象](#def_commit_object)的简写。 作为动词：通过创建表示[索引](#def_index)当前状态的新提交并将 [HEAD](#def_HEAD) 推进指向新的提交。 ``` commit object ``` [对象](#def_object)包含有关特定[修订版](#def_revision)的信息，如[父](#def_parent)，提交者，作者，日期和[树对象](#def_tree_object)对应到存储修订的顶部[目录](#def_directory)。 ``` commit-ish (also committish) ``` [提交对象](#def_commit_object)或[对象](#def_object)，可以递归地解除引用到提交对象。以下是commit-ishes：提交对象，指向提交对象的[标记对象](#def_tag_object)，指向指向提交对象的标记对象的标记对象，等等。 ``` core Git ``` Git的基本数据结构和实用程序。仅公开有限的源代码管理工具。 ``` DAG ``` 有向无环图。 [提交对象](#def_commit_object)形成一个有向无环图，因为它们有父对象（有向），而提交对象的图是非循环的（没有[链](#def_chain)开始和结束相同[对象](#def_object)）。 ``` dangling object ``` [无法到达的对象](#def_unreachable_object)即使从其他无法到达的对象也不能[到达](#def_reachable);悬挂物体没有从[存储库](#def_repository)中的任何参考或[对象](#def_object)引用它。 ``` detached HEAD ``` 通常， [HEAD](#def_HEAD) 存储[分支](#def_branch)的名称，并且对历史HEAD进行操作的命令表示对通向HEAD指向的分支的尖端的历史进行操作。但是，Git还允许你[检查](#def_checkout)任意[提交](#def_commit)，这不一定是任何特定分支的提示。处于这种状态的HEAD被称为“分离的”。 请注意，在HEAD分离时，对当前分支的历史记录进行操作的命令（例如，`git commit`以在其上构建新历史记录）仍然有效。他们更新HEAD以指向更新历史记录的提示，而不会影响任何分支。更新或查询关于当前分支的信息_的命令（例如设置当前分支与哪个远程跟踪分支集成的`git branch --set-upstream-to`）显然不起作用，因为没有（实际）当前分支要求在这种状态下。_ ``` directory ``` 你用“ls”得到的清单:-) ``` dirty ``` 如果[工作树](#def_working_tree)包含尚未[提交](#def_commit)到当前[分支](#def_branch)的修改，则称其为“脏”。 ``` evil merge ``` 邪恶合并是[合并](#def_merge)，它引入了未出现在任何[父](#def_parent)中的变化。 ``` fast-forward ``` 快进是一种特殊类型的[合并](#def_merge)你有一个[修订](#def_revision)并且你正在“合并”另一个[分支](#def_branch)的变化恰好是一个后代你有什么在这种情况下，你不会进行新的[合并](#def_merge) [提交](#def_commit)，而只是更新到他的修订版。这将在远程[存储库](#def_repository)的[远程跟踪分支](#def_remote_tracking_branch)上频繁发生。 ``` fetch ``` 获取[分支](#def_branch)意味着从远程[存储库](#def_repository)获取分支的 [head ref](#def_head_ref) ，以找出本地[对象数据库中缺少的对象](#def_object_database) ]，也是为了得到它们。另见 [git-fetch [1]](https://git-scm.com/docs/git-fetch) 。 ``` file system ``` Linus Torvalds最初将Git设计为用户空间文件系统，即保存文件和目录的基础设施。这确保了Git的效率和速度。 ``` Git archive ``` [存储库](#def_repository)的同义词（适用于拱门人员）。 ``` gitfile ``` 位于工作树根目录的纯文件`.git`，指向作为真实存储库的目录。 ``` grafts ``` 通过记录提交的伪造祖先信息，移植物可以将两个不同的开发线连接在一起。这样你就可以让Git假装[父](#def_parent) [提交](#def_commit)的集合与创建提交时记录的不同。通过`.git/info/grafts`文件配置。 请注意，移植机制已过时，可能导致在存储库之间传输对象时出现问题;请参阅 [git-replace [1]](https://git-scm.com/docs/git-replace) 以获得更灵活，更强大的系统来执行相同的操作。 ``` hash ``` 在Git的上下文中，[对象名称](#def_object_name)的同义词。 ``` head ``` [在](#def_ref)[分支](#def_branch)的末端命名为[提交](#def_commit)的参考。磁头存储在`$GIT_DIR/refs/heads/`目录中的文件中，除非使用压缩参考。 （参见 [git-pack-refs [1]](https://git-scm.com/docs/git-pack-refs) 。） ``` HEAD ``` 当前[分支](#def_branch)。更详细：您的[工作树](#def_working_tree)通常来自HEAD引用的树的状态。 HEAD是对您的存储库中 [](#def_head) 之一的引用，除非使用[分离的HEAD](#def_detached_HEAD) ，在这种情况下它直接引用任意提交。 ``` head ref ``` [head](#def_head) 的同义词。 ``` hook ``` 在几个Git命令的正常执行期间，对可选脚本进行调用，允许开发人员添加功能或检查。通常，挂钩允许预先验证并可能中止命令，并允许在操作完成后进行后通知。钩子脚本位于`$GIT_DIR/hooks/`目录中，只需从文件名中删除`.sample`后缀即可启用。在早期版本的Git中，您必须使它们可执行。 ``` index ``` 包含stat信息的文件集合，其内容存储为对象。索引是[工作树](#def_working_tree)的存储版本。说实话，它还可以包含工作树的第二个甚至第三个版本，这些版本在[合并](#def_merge)时使用。 ``` index entry ``` 有关特定文件的信息，存储在[索引](#def_index)中。如果[合并](#def_merge)已启动但尚未完成（即，如果索引包含该文件的多个版本），则索引条目可以是未合并的。 ``` master ``` 默认开发[分支](#def_branch)。无论何时创建Git [存储库](#def_repository)，都会创建一个名为“master”的分支，并成为活动分支。在大多数情况下，这包含本地开发，虽然这纯粹是按照惯例而不是必需的。 ``` merge ``` 作为动词：将另一个[分支](#def_branch)（可能来自外部[存储库](#def_repository)）的内容带入当前分支。在合并分支来自不同存储库的情况下，这通过首先[获取](#def_fetch)远程分支然后将结果合并到当前分支来完成。这种获取和合并操作的组合称为 [pull](#def_pull) 。合并由一个自动过程执行，该过程识别自分支分叉后所做的更改，然后将所有这些更改一起应用。如果更改发生冲突，则可能需要手动干预才能完成合并。 作为名词：除非它是[快进](#def_fast_forward)，否则成功合并会导致创建表示合并结果的新[提交](#def_commit)，并具有[父](#def_parent)合并[分支](#def_branch)的提示。此提交称为“合并提交”，有时仅称为“合并”。 ``` object ``` Git中的存储单元。它由 [SHA-1](#def_SHA1) 的内容唯一标识。因此，不能改变对象。 ``` object database ``` 存储一组“对象”，单个[对象](#def_object)由其[对象名称](#def_object_name)标识。对象通常存在于`$GIT_DIR/objects/`中。 ``` object identifier ``` [对象名称](#def_object_name)的同义词。 ``` object name ``` [对象](#def_object)的唯一标识符。对象名称通常由40个字符的十六进制字符串表示。通俗地称为 [SHA-1](#def_SHA1) 。 ``` object type ``` 其中一个标识符“[提交](#def_commit_object)”，“[树](#def_tree_object)”，“[标签](#def_tag_object)”或“ [blob](#def_blob_object) ”描述[HTG8的类型对象。 ``` octopus ``` [合并](#def_merge)超过两个[分支](#def_branch)。 ``` origin ``` 默认上游[存储库](#def_repository)。大多数项目至少有一个他们跟踪的上游项目。默认情况下_原点_用于此目的。新的上游更新将被提取到名为origin / name-of-upstream-branch的[远程跟踪分支](#def_remote_tracking_branch)中，您可以使用`git branch -r`查看。 ``` pack ``` 已压缩到一个文件中的一组对象（以节省空间或有效传输它们）。 ``` pack index ``` [包](#def_pack)中对象的标识符列表和其他信息，以帮助有效地访问包的内容。 ``` 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]](https://git-scm.com/docs/gitattributes) 。 路径的每个属性要求都采用以下形式之一： * “`ATTR`”要求设置属性`ATTR`。 * “`-ATTR`”要求取消设置`ATTR`属性。 * “`ATTR=VALUE`”要求将属性`ATTR`设置为字符串`VALUE`。 * “`!ATTR`”要求未指定属性`ATTR`。 请注意，在对树对象进行匹配时，仍然可以从工作树获取属性，而不是从给定的树对象获取属性。 ``` exclude ``` 在路径匹配任何非排除路径规范后，它将运行所有排除路径规范（魔术签名：`!`或其同义词`^`）。如果匹配，则忽略该路径。如果没有非排除路径规范，则将排除应用于结果集，就像在没有任何pathspec的情况下调用一样。 ``` parent ``` [提交对象](#def_commit_object)包含开发线中的逻辑前任（即其父项）的（可能是空的）列表。 ``` pickaxe ``` 术语 [pickaxe](#def_pickaxe) 是指diffcore例程的一个选项，它有助于选择添加或删除给定文本字符串的更改。使用`--pickaxe-all`选项，它可用于查看引入或删除的完整[变更集](#def_changeset)，例如特定的文本行。参见 [git-diff [1]](https://git-scm.com/docs/git-diff) 。 ``` plumbing ``` [核心Git](#def_core_git) 的可爱名称。 ``` porcelain ``` 程序和程序套件的可爱名称取决于[核心Git](#def_core_git) ，提供对核心Git的高级访问。与[管道](#def_plumbing)相比，瓷器暴露出更多的 [SCM](#def_SCM) 界面。 ``` per-worktree ref ``` 根据[工作树](#def_working_tree)的参考，而不是全局。目前只有 [HEAD](#def_HEAD) 以及以`refs/bisect/`开头的任何引用，但后来可能包括其他不寻常的引用。 ``` pseudoref ``` Pseudorefs是`$GIT_DIR`下的一类文件，其行为类似于refs用于rev-parse，但是由git专门处理。伪数据都具有全大写的名称，并且始终以包含 [SHA-1](#def_SHA1) 后跟空格的行开头。因此，HEAD不是伪目标，因为它有时是一个象征性的参考。它们可以选择包含一些其他数据。 `MERGE_HEAD`和`CHERRY_PICK_HEAD`是示例。与 [per-worktree refs](#def_per_worktree_ref) 不同，这些文件不能是符号引用，也不会有reflog。它们也无法通过正常的ref更新机器进行更新。相反，它们通过直接写入文件来更新。但是，它们可以被读作好像是参考，因此`git rev-parse MERGE_HEAD`将起作用。 ``` pull ``` 拉[分支](#def_branch)意味着[获取](#def_fetch)它和[合并](#def_merge)它。另见 [git-pull [1]](https://git-scm.com/docs/git-pull) 。 ``` push ``` 推动[分支](#def_branch)意味着从远程[存储库](#def_repository)获取分支的[头部参考](#def_head_ref)，找出它是否是分支的本地头部参考的祖先，并且case，将[可以从本地head ref访问的对象](#def_reachable)和远程存储库中缺失的对象放入远程[对象数据库](#def_object_database)，并更新远程头部ref。如果远程[头](#def_head)不是本地磁头的祖先，则推送失败。 ``` reachable ``` 给定[提交](#def_commit)的所有祖先都被认为是来自该提交的“可达”。更一般地说，一个[对象](#def_object)可以从另一个到达，如果我们可以通过[链](#def_chain)跟随[标签](#def_tag)到达另一个到它们标记的任何东西，[将](#def_commit_object)提交给他们的父母或树木，将[树](#def_tree_object)提交给他们所包含的树木或 [blob](#def_blob_object) 。 ``` rebase ``` 要重新应用从[分支](#def_branch)到不同基数的一系列更改，并将该分支的[头](#def_head)重置为结果。 ``` ref ``` 以`refs/`开头的名称（例如`refs/heads/master`）指向[对象名称](#def_object_name)或另一个ref（后者称为[符号ref](#def_symref) ））。为方便起见，当用作Git命令的参数时，ref有时可以缩写;有关详细信息，请参阅 [gitrevisions [7]](https://git-scm.com/docs/gitrevisions) 。 Refs存储在[存储库](#def_repository)中。 ref命名空间是分层的。不同的子层次结构用于不同的目的（例如，`refs/heads/`层次结构用于表示本地分支）。 有一些特殊用途的参考不以`refs/`开头。最值得注意的例子是`HEAD`。 ``` reflog ``` reflog显示ref的本地“历史”。换句话说，它可以告诉你_这个_存储库中的第3个最后修订是什么，以及昨天晚上9点14分_这个_存储库中的当前状态是什么。有关详细信息，请参阅 [git-reflog [1]](https://git-scm.com/docs/git-reflog) 。 ``` refspec ``` [fetch](#def_fetch) 和 [push](#def_push) 使用“refspec”来描述远程 [ref](#def_ref) 和本地ref之间的映射。 ``` remote repository ``` [存储库](#def_repository)，用于跟踪同一个项目但位于其他地方。要与遥控器通信，请参阅[获取](#def_fetch)或[按](#def_push)。 ``` remote-tracking branch ``` [ref](#def_ref) ，用于跟踪来自另一个[存储库](#def_repository)的更改。它通常看起来像 _refs / remotes / foo / bar_ （表示它在名为 _foo_ 的遥控器中跟踪一个名为 _bar_ 的分支），并且匹配右边 - 已配置的提取 [refspec](#def_refspec) 的手边。远程跟踪分支不应包含直接修改或对其进行本地提交。 ``` repository ``` [refs](#def_ref) 的集合以及[对象数据库](#def_object_database)，其中包含来自refs的[可达](#def_reachable)的所有对象，可能伴随来自一个或多个[瓷器的元数据](#def_porcelain)。存储库可以通过[交替机制](#def_alternate_object_database)与其他存储库共享对象数据库。 ``` resolve ``` 手动修复失败的自动[合并](#def_merge)留下的动作。 ``` revision ``` [commit](#def_commit) （名词）的同义词。 ``` rewind ``` 抛弃部分开发，即将[头](#def_head)分配给早期[修订版](#def_revision)。 ``` SCM ``` 源代码管理（工具）。 ``` SHA-1 ``` “安全哈希算法1”;加密哈希函数。在Git的上下文中用作[对象名称](#def_object_name)的同义词。 ``` shallow clone ``` 通常是[浅存储库](#def_shallow_repository)的同义词，但该短语使其更明确地表示它是通过运行`git clone --depth=...`命令创建的。 ``` shallow repository ``` 一个浅[存储库](#def_repository)有一个不完整的历史，其中一些[提交](#def_commit)有[父母](#def_parent)烧灼（换句话说，Git被告知假装这些提交没有父母，即使他们被记录在[提交对象](#def_commit_object)中）。当您仅对项目的近期历史感兴趣时，这有时很有用，即使上游记录的真实历史要大得多。通过向 [git-clone [1]](https://git-scm.com/docs/git-clone) 提供`--depth`选项来创建浅存储库，并且可以稍后使用 [git-fetch [1]](https://git-scm.com/docs/git-fetch) 加深其历史记录。 ``` stash entry ``` [对象](#def_object)用于临时存储[脏](#def_dirty)工作目录的内容和索引以供将来重用。 ``` submodule ``` [存储库](#def_repository)，用于保存另一个存储库中的单独项目的历史记录（后者称为 [superproject](#def_superproject) ）。 ``` superproject ``` [存储库](#def_repository)，它将工作树中其他项目的存储库作为[子模块](#def_submodule)引用。超级项目知道所包含的子模块的提交对象的名称（但不包含其副本）。 ``` symref ``` 符号引用：它不是包含 [SHA-1](#def_SHA1) id本身，而是格式为 _ref：refs / some / thing_ ，并且在引用时，它递归地取消引用此引用。 _[HEAD](#def_HEAD) _是symref的主要示例。使用 [git-symbolic-ref [1]](https://git-scm.com/docs/git-symbolic-ref) 命令操纵符号引用。 ``` tag ``` `refs/tags/`命名空间下的 [ref](#def_ref) 指向任意类型的对象（通常标签指向[标签](#def_tag_object)或[提交对象](#def_commit_object)）。与[头](#def_head)相反，`commit`命令不会更新标签。 Git标签与Lisp标签无关（在Git的上下文中称为[对象类型](#def_object_type)）。标记最常用于标记提交祖先[链](#def_chain)中的特定点。 ``` tag object ``` 包含 [ref](#def_ref) 的[对象](#def_object)指向另一个对象，该对象可以包含类似[提交对象](#def_commit_object)的消息。它还可以包含（PGP）签名，在这种情况下，它被称为“签名标记对象”。 ``` topic branch ``` 一个常规的Git [分支](#def_branch)，开发人员用它来识别概念的开发线。由于分支非常容易且便宜，因此通常需要具有若干小分支，每个小分支包含非常明确定义的概念或小的增量但相关的变化。 ``` tree ``` [工作树](#def_working_tree)或[树对象](#def_tree_object)与从属 [blob](#def_blob_object) 和树对象（即工作树的存储表示）一起。 ``` tree object ``` 包含文件名和模式列表的[对象](#def_object)以及对关联的blob和/或树对象的引用。 [树](#def_tree)相当于[目录](#def_directory)。 ``` tree-ish (also treeish) ``` [树对象](#def_tree_object)或[对象](#def_object)，可以递归地解除引用到树对象。解除引用[提交对象](#def_commit_object)产生对应于[修订版](#def_revision)的顶部[目录](#def_directory)的树对象。以下是所有树形图： [commit-ish](#def_commit-ish) ，树对象，指向树对象的[标记对象](#def_tag_object)，指向指向标记对象的标记对象到树对象等 ``` unmerged index ``` [索引](#def_index)包含未合并的[索引条目](#def_index_entry)。 ``` unreachable object ``` 来自[分支](#def_branch)，[标签](#def_tag)或任何其他参考的[对象](#def_object)不是[可到达的](#def_reachable)。 ``` upstream branch ``` 合并到相关分支中的默认[分支](#def_branch)（或者有问题的分支被重新分配到）。它通过分支配置。< name> .remote和branch。< name> .merge。如果 _A_ 的上游分支是_起源/ B_ ，有时我们说“ _A_ 正在追踪_起源/ B_ ”。 ``` working tree ``` 实际签出文件的树。工作树通常包含 [HEAD](#def_HEAD) 提交树的内容，以及您已经进行但尚未提交的任何本地更改。 ## 也可以看看 [gittutorial [7]](https://git-scm.com/docs/gittutorial) ， [gittutorial-2 [7]](https://git-scm.com/docs/gittutorial-2) ， [gitcvs-migration [7]](https://git-scm.com/docs/gitcvs-migration) ， [giteveryday [7]](https://git-scm.com/docs/giteveryday) ， [Git用户手册](user-manual.html) ## GIT 部分 [git [1]](https://git-scm.com/docs/git) 套件