gitglossary

gitglossary

名称

gitglossary - Git词汇表

概要

描述

备用对象数据库

通过交替机制，存储库可以从另一个对象数据库继承其对象数据库的一部分，这被称为“备用”。

空仓

显式的存储库通常是一个适当命名的目录，其.git后缀没有在版本控制下的任何文件的本地签出副本。也就是说，通常存在于隐藏.git子目录中的所有Git管理和控制文件都直接出现在repository.git目录中，而不存在和检出其他文件。通常，公共存储库的发布者会使显式的存储库可用。

blob 对象

非类型化的对象，例如文件的内容。

分支

“分支”是一个积极的发展路线。分支上最近的提交被称为分支的提示。分支的顶端由分支头引用，随着分支上的额外开发，分支头向前移动。一个Git仓库可以跟踪任意数量的分支，但您的工作树仅与其中一个分支（“当前”或“签出”分支）关联，并且HEAD指向该分支。

高速缓存

已弃用：索引。

链

对象列表，其中列表中的每个对象都包含对其后继者的引用（例如，提交的后继者可以是其父代之一）。

变更

BitKeeper / cvsps 代表“提交”。由于 Git 不存储更改，但使用 Git 的术语 “changesets” 确实没有意义。

查看

使用对象数据库中的树对象或 blob 更新全部或部分工作树，以及在整个工作树已指向新分支的情况下更新索引和 HEAD 的操作。

cherry-picking

在 SCM 专业术语中，“ cherry-picking ” 意味着从一系列更改（通常为提交）中选择一部分更改，并将它们记录为不同代码库之上的一系列新更改。在 Git 中，这由 “git cherry-pick” 命令执行，以提取现有引入的提交更改，并根据当前分支的提示将其记录为新提交。

清除

A working tree is clean, if it corresponds to the revision referenced by the current head. Also see "dirty".

commit

作为名词：Git 历史中的单一点; 一个项目的整个历史被表示为一组相互关联的提交。Git经常在相同的地方使用 “commit” 一词，而其他版本控制系统使用“revision”或“version”一词。也用作提交对象的简写。

作为动词：通过创建一个代表索引当前状态的新提交并推进 HEAD 指向新的提交，将项目状态的新快照存储在 Git 历史记录中的操作。

commit 对象

对象，其中包含有关特定修订版的信息，例如父项，提交者，作者，日期和与所存储的修订版顶部目录相对应的树对象。

commit-ish (also committish)

提交对象或可递归解引用到提交对象的对象。以下是所有提交：提交对象，指向提交对象的标记对象。

Git 核心

Git 的基本数据结构和实用程序。只公开有限的源代码管理工具。

DAG

有向无循环图。提交对象形成一个有向无循环图，因为它们具有父（定向），并且提交对象的图是非循环的（不存在以相同对象开始和结束的链）。

dangling object

即使从其他不可达对象也无法访问不可访问对象; 一个悬挂对象没有从存储库中的任何引用，或没有对象引用它。

分离 HEAD

通常，HEAD 存储分支的名称，并且对历史 HEAD 进行操作的命令表示对通向 HEAD 指向的分支尖端的历史进行操作。但是，Git 还允许您检出任意提交，但不一定是任何特定分支的提示。这种状态下的 HEAD 被称为“分离”。

请注意，在当前分支的历史记录上运行的命令（例如git commit，在其上创建新的历史记录）在 HEAD 分离时仍然有效。他们更新 HEAD 指向更新后的历史记录，而不影响任何分支。更新或查询about当前分支信息的命令（例如git branch --set-upstream-to，设置当前分支集成的远程跟踪分支）显然不起作用，因为在此状态下没有（实际）当前分支要求。

目录

你用 “ls” 得到的名单:-)

dirty

如果工作树包含尚未提交给当前分支的修改，则称其为“ dirty ”。

evil merge

evil merge 是一种合并，它引入了不出现在任何父代中的变化。

fast-forward

fast-forward 是一种特殊的合并类型，您可以在其中进行修改，并且您正在 “merging” 另一个分支的变更，这些变更恰好是您所拥有的后代。在这种情况下，您不必进行新的合并提交，而只需更新其修订。这将经常发生在远程存储库的远程跟踪分支上。

fetch

获取分支意味着从远程存储库获取分支的头部引用，以找出本地对象数据库中缺少哪些对象，并获取它们。另请参阅 git-fetch [1] 。

文件系统

Linus Torvalds 最初将 Git 设计为用户空间文件系统，即保存文件和目录的基础架构。这确保了 Git 的效率和速度。

Git 存档

资源库的同义词（适用于 arch 人士）。

gitfile

.git工作树根部的纯文件，指向真实存储库的目录。

grafts

嫁接使两个不同的发展路线通过记录提交的虚假血统信息连接在一起。通过这种方式，你可以让 Git 假装一个提交的父集与创建提交时所记录的不同。通过.git/info/grafts文件进行配置。

Note that the grafts mechanism is outdated and can lead to problems transferring objects between repositories; see git-replace[1] for a more flexible and robust system to do the same thing.

hash

在 Git 的上下文中，对象名的同义词。

head

对分支顶端提交的命名引用。头文件存储在$GIT_DIR/refs/heads/目录中的文件中，除非使用打包引用。（请参阅 git-pack-refs [1] 。）

HEAD

当前分支。更详细地说：你的工作树通常是由 HEAD 引用的树的状态派生的。除了使用分离 HEAD 时，HEAD 是对存储库中某个头的引用，在这种情况下，它直接引用任意提交。

head ref

头部的同义词。

hook

在正常执行几个 Git 命令的过程中，对可选脚本进行了标注，以便开发人员添加功能或进行检查。通常，钩子允许预先验证命令并可能中止，并且在完成操作之后允许后通知。hook 脚本可以在$GIT_DIR/hooks/目录中找到，只需.sample从文件名中删除后缀即可启用。在 Git 的早期版本中，你必须让它们可执行。

index

包含 stat 信息的文件集合，其内容以对象形式存储。索引是工作树的存储版本。真相被告知，它也可以包含合并时使用的第二个，甚至第三个工作树版本。

index entry

有关特定文件的信息，存储在索引中。如果合并已启动，但尚未完成（即索引包含该文件的多个版本），则索引条目可以取消合并。

master

默认开发分支。无论何时创建 Git 存储库，都会创建一个名为 “master” 的分支，并成为活动分支。在大多数情况下，这包含了当地的发展，尽管这纯粹是按照惯例，并不是必需的。

merge

作为动词：将另一个分支的内容（可能来自外部存储库）引入当前分支。在合并分支来自不同的存储库的情况下，首先获取远程分支，然后将结果合并到当前分支中。提取和合并操作的组合称为拉取。合并由一个自动过程执行，该过程识别自分支发散后所做的更改，然后将所有这些更改应用到一起。如果更改有冲突，可能需要手动干预才能完成合并。

作为名词：除非是快进，否则成功的合并会导致创建代表合并结果的新提交，并将合并分支的提示作为父项。这个提交被称为“合并提交”，或者有时候只是一个“合并”。

object

Git 中的存储单元。它由 SHA-1 的内容唯一标识。因此，对象不能改变。

object 数据库

存储一组 “object”，单个对象由其对象名称标识。物体通常存储在$GIT_DIR/objects/。

object 标识符

object 名称的同义词。

object 名称

object 的唯一标识符。对象名称通常由40个字符的十六进制字符串表示。俗称 SHA-1。

object 类型

描述对象类型的标识符 “commit”，“tree”，“tag” 或 “blob” 之一。

octopus

合并两个以上的分支。

origin

默认的上游存储库。大多数项目至少有一个跟踪的上游项目。默认情况下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 表示一个目录前缀。pathspec 的范围仅限于该子树。

• pathpec 的其余部分是路径名剩余部分的模式。相对于目录前缀的路径将使用fnmatch（3） 与该模式进行匹配; 特别是，*和? can匹配目录 separators.For 例如，文档/ *。JPG 将匹配在文档子树的所有.jpg文件，包括文档 / chapter_1 / figure_1.jpg.A pathspec 开头用冒号:具有特殊的意义。简而言之，前面的冒号:后面是零个或多个“魔术签名”字母（可选地由另一个冒号终止:），剩下的就是匹配路径的模式。“魔术签名”由 ASCII 字母组成，既不是字母数字，glob，正则表达式特殊字符也不是冒号。如果模式以不属于“魔术签名”符号集且不是冒号的字符开始，则可以省略可选冒号以终止“魔术签名”。在长形式中，前导冒号:后面是开放圆括号(，以逗号分隔的零个或多个“魔术字”列表和一个紧密的括号)，其余部分是匹配路径的模式。仅带冒号的 pathspec 意味着“没有 pathspec ”。此表单不应与其他 pathspec 结合使用。顶部魔术字top（魔法签名：/）使模式与工作树的根相匹配，即使在子目录中运行命令时也是如此。模式中的文字通配符，例如*或被?视为文字字符。icase不区分大小写匹配。glob Gi t将模式视为适合 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/**” .gitignore以无限深度匹配目录“abc”内相对于文件位置的所有文件。

• 斜杠后跟两个连续的星号，则斜线匹配零个或多个目录。例如，“ a/**/b”匹配“ a/b”，“ a/x/b”，“ a/x/y/b”等。

• 其他连续的星号被认为是无效的。Glob魔法与字面魔法不相容。attr在attr:出现空格分隔的“属性要求”列表之后，必须满足所有这些才能使路径被视为匹配; 这是除了通常的非 magicitespec 模式匹配外。请参阅 gitattributes [5] 。路径的每个属性需求都采用以下形式之一：

• “ ATTR”要求ATTR设置属性。

• “ -ATTR” 要求属性ATTR未设置。

• “ ATTR=VALUE” 要求将属性ATTR设置为字符串VALUE。

• “ !ATTR” 要求属性ATTR未指定。

排除

路径匹配任何非排除的pathspec后，它将通过所有排除路径规范（魔术签名：!或其同义词^）运行。如果匹配，路径将被忽略。如果不存在非排除的 pathspec，则将排除应用于结果集，就像调用没有任何 pathspec 一样。

parent

提交对象包含一个（可能是空的）在开发线中的逻辑前驱者列表，即它的父代。

pickaxe

术语 pickaxe 指 diffcore 例程的一个选项，它帮助选择添加或删除给定文本字符串的更改。有了这个--pickaxe-all选项，它可以用来查看引入或删除的完整变更集，比如说一行文本。参见 git-diff [1]。

plumbing

核心 Git 的名字。

porcelain

程序和程序套件的名字取决于核心 Git，提供对核心 Git 的高级访问。Porcelains 公开了比管道更多的 SCM 界面。

per-worktree ref

参考文献是每个工作树，而不是全局。目前只有 HEAD 和任何以 ref 开头的 ref refs/bisect/，但后来可能会包含其他不寻常的 ref。

pseudoref

Pseudorefs 是一类文件，在$GIT_DIR这类文件中，为了 rev-parse 的目的，其行为类似于 refs，但是它们被 git 特别处理。伪代码都具有全部大写的名称，并且始终以包含 SHA-1 和空白的行开头。所以，HEAD 不是一个伪造的，因为它有时是一个符号参考。他们可以选择包含一些额外的数据。MERGE_HEAD并且CHERRY_PICK_HEAD是例子。不像per-worktree refs，这些文件不能是符号参考，也不会有 reflog。他们也不能通过正常的参考更新机器进行更新。相反，它们是通过直接写入文件来更新的。然而，他们可以被看作是裁判，所以git rev-parse MERGE_HEAD会工作。

pull

pull 分支意味着获取并合并它。另见 git-pull [1]。

push

push 分支意味着从远程存储库获取分支的头部引用，找出它是否是分支的本地头引用的直接祖先，并且在这种情况下，将所有可从本地头引用获得的对象，以及哪些从远程存储库中丢失，进入远程对象数据库，并更新远程头参考。如果远程头部不是本地头部的父类，则推送失败。

reachable

所有提交的父类都被认为是“可达”的。更一般地说，如果我们可以通过跟随标签跟随标签的链向另一个发送另一个对象，那么可以从另一个对象到达另一个对象，向他们的父类或 commit，向树木或其包含的 blob commit。

rebase

要重新应用从一个分支到另一个基地的一系列更改，并将该分支的头部重置为结果。

ref

以refs/（例如refs/heads/master）开头的名称指向一个对象名称或另一个引用（后者称为符号引用）。为方便起见，当用 Git 命令的参数时，ref 有时可以缩写; 有关详细信息，请参阅 gitrevisions [7]。参考资料存储在存储库中。

参考命名空间是分层的。不同的refs/heads/子层次结构用于不同的目的（例如，层次结构用于表示本地分支）。

有一些特殊用途的参考文献不是以refs/开头的。最显著的例子是HEAD。

reflog

reflog显示参考文献的本地“历史”。换句话说，this可以告诉你存储库中第3次修订版本是什么，以及当前this存储库中的状态是什么，如昨天晚上9点14分。有关详细信息，请参阅 git-reflog [1]。

refspec

提取和推送使用“refspec”来描述远程参考和本地参考之间的映射。

远程存储库

用于跟踪相同项目但驻留在其他位置的存储库。要与遥控器通信，请参阅提取或推送。

远程跟踪分支

用于跟踪另一个存储库的更改的引用。它通常看起来像refs/remotes/foo/bar（表示它跟踪名为bar远程命名的分支foo），并匹配配置的提取refspec的右侧。远程追踪分支不应包含直接修改或本地提交。

知识库

ref 集合以及对象数据库，其中包含所有可从 ref 中获得的对象，可能伴随着来自一个或多个 porcelains 的元数据。存储库可以通过交替机制与其他存储库共享对象数据库。

解决

手动修复失败的自动合并留下的操作。

调整

提交的同义词（名词）。

rewind

放弃部分发展，即将头部分配给较早的修订。

SCM

源代码管理（工具）。

SHA-1

“安全散列算法1”; 一个密码散列函数。在使用 Git 作为对象名称的同义词的上下文中。

shallow clone

大多数情况下，它是浅层存储库的同义词，但该语句使得它更加明确，它是通过运行git clone --depth=...命令创建的。

shallow repository

浅仓库有一个不完整的历史记录，其中一些提交被父母烧掉（换句话说，Git被告知假设这些提交没有父母，即使它们被记录在提交对象中）。即使在上游记录的真实历史要大得多，当你仅仅关注项目的最近历史时，这有时也很有用。通过给--depthgit-clone [1] 选项创建一个浅仓库，其历史可以通过 git-fetch [1] 加深。

stash entry

用于临时存储脏工作目录和索引以供将来重用的内容的对象。

submodule

在另一个存储库（后者称为超级项目）中存储单独项目历史的存储库。

superproject

将工作树中其他项目的存储库作为子模块引用的存储库。超级项目知道所包含子模块的提交对象的名称（但不保存其副本）。

symref

符号引用：它不是包含 SHA-1 标识本身，而是它的格式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)

树对象或可递归解引用到树对象的对象。取消引用提交对象会生成与修订版顶部目录对应的树对象。以下是所有树形结构：提交对象，树对象，指向树对象的标记对象。

未合并指数

包含未合并索引条目的索引。

无法访问的对象

无法从分支，标记或任何其他参考访问的对象。

上游分支

合并到问题分支（或分支问题的分支）的默认分支被重新分配到。它通过分支<name> .remote 和分支。<名称> .merge 进行配置。如果上游分支A是origin/B有时候我们说“ A被跟踪origin/B”。

working tree

实际检出文件的树。工作树通常包含 HEAD 提交树的内容，以及您所做的但尚未提交的任何本地更改。