gitglossary

原文： https://git-scm.com/docs/gitglossary

名称

gitglossary - Git词汇表

概要

*

描述

  1.  alternate object database

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

  1.  bare repository

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

  1.  blob object

未输入的对象，例如文件的内容。

  1.  branch

“分支”是一个积极的发展路线。分支上最近的提交被称为该分支的提示。分支的尖端由分支头引用，其在分支上进行额外的开发时向前移动。单个Git 存储库可以跟踪任意数量的分支，但您的工作树只与其中一个（“当前”或“已检出”分支）相关联， HEAD 指向那个分支。

  1.  cache

已废弃：索引。

  1.  chain

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

  1.  changeset

BitKeeper / cvsps代表“ commit ”。由于Git不存储更改，但是状态，因此在Git中使用术语“changesets”实际上没有意义。

  1.  checkout

用来自对象数据库的树对象或 blob 更新全部或部分工作树的动作，并更新索引和 HEAD 如果整个工作树已指向新的分支。

  1.  cherry-picking

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

  1.  clean

工作树是干净的，如果它对应于当前头引用的修订版。另见“脏”。

  1.  commit

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

作为动词：通过创建表示索引当前状态的新提交并将 HEAD 推进指向新的提交。

  1.  commit object

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

  1.  commit-ish (also committish)

提交对象或对象，可以递归地解除引用到提交对象。以下是commit-ishes：提交对象，指向提交对象的标记对象，指向指向提交对象的标记对象的标记对象，等等。

  1.  core Git

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

  1.  DAG

有向无环图。 提交对象形成一个有向无环图，因为它们有父对象（有向），而提交对象的图是非循环的（没有链开始和结束相同对象）。

  1.  dangling object

无法到达的对象即使从其他无法到达的对象也不能到达;悬挂物体没有从存储库中的任何参考或对象引用它。

  1.  detached HEAD

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

请注意，在HEAD分离时，对当前分支的历史记录进行操作的命令（例如，git commit以在其上构建新历史记录）仍然有效。他们更新HEAD以指向更新历史记录的提示，而不会影响任何分支。更新或查询关于当前分支的信息的命令（例如设置当前分支与哪个远程跟踪分支集成的git branch --set-upstream-to）显然不起作用，因为没有（实际）当前分支要求在这种状态下。

  1.  directory

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

  1.  dirty

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

  1.  evil merge

邪恶合并是合并，它引入了未出现在任何父中的变化。

  1.  fast-forward

快进是一种特殊类型的合并你有一个修订并且你正在“合并”另一个分支的变化恰好是一个后代你有什么在这种情况下，你不会进行新的合并 提交，而只是更新到他的修订版。这将在远程存储库的远程跟踪分支上频繁发生。

  1.  fetch

获取分支意味着从远程存储库获取分支的 head ref ，以找出本地对象数据库中缺少的对象 ]，也是为了得到它们。另见 git-fetch [1] 。

  1.  file system

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

  1.  Git archive

存储库的同义词（适用于拱门人员）。

  1.  gitfile

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

  1.  grafts

通过记录提交的伪造祖先信息，移植物可以将两个不同的开发线连接在一起。这样你就可以让Git假装父 提交的集合与创建提交时记录的不同。通过.git/info/grafts文件配置。

请注意，移植机制已过时，可能导致在存储库之间传输对象时出现问题;请参阅 git-replace [1] 以获得更灵活，更强大的系统来执行相同的操作。

  1.  hash

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

  1.  head

在分支的末端命名为提交的参考。磁头存储在$GIT_DIR/refs/heads/目录中的文件中，除非使用压缩参考。 （参见 git-pack-refs [1] 。）

  1.  HEAD

当前分支。更详细：您的工作树通常来自HEAD引用的树的状态。 HEAD是对您的存储库中 之一的引用，除非使用分离的HEAD ，在这种情况下它直接引用任意提交。

  1.  head ref

head 的同义词。

  1.  hook

在几个Git命令的正常执行期间，对可选脚本进行调用，允许开发人员添加功能或检查。通常，挂钩允许预先验证并可能中止命令，并允许在操作完成后进行后通知。钩子脚本位于$GIT_DIR/hooks/目录中，只需从文件名中删除.sample后缀即可启用。在早期版本的Git中，您必须使它们可执行。

  1.  index

包含stat信息的文件集合，其内容存储为对象。索引是工作树的存储版本。说实话，它还可以包含工作树的第二个甚至第三个版本，这些版本在合并时使用。

  1.  index entry

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

  1.  master

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

  1.  merge

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

作为名词：除非它是快进，否则成功合并会导致创建表示合并结果的新提交，并具有父合并分支的提示。此提交称为“合并提交”，有时仅称为“合并”。

  1.  object

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

  1.  object database

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

  1.  object identifier

对象名称的同义词。

  1.  object name

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

  1.  object type

其中一个标识符“提交”，“树”，“标签”或“ blob ”描述[HTG8的类型对象。

  1.  octopus

合并超过两个分支。

  1.  origin

默认上游存储库。大多数项目至少有一个他们跟踪的上游项目。默认情况下原点用于此目的。新的上游更新将被提取到名为origin / name-of-upstream-branch的远程跟踪分支中，您可以使用git branch -r查看。

  1.  pack

已压缩到一个文件中的一组对象（以节省空间或有效传输它们）。

  1.  pack index

包中对象的标识符列表和其他信息，以帮助有效地访问包的内容。

  1.  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结合使用。

  1.  top

即使从子目录中运行命令，魔术字top（魔术签名：/）也会使工作树的根模式匹配。

  1.  literal

模式中的通配符（如*或?）被视为文字字符。

  1.  icase

不区分大小写的匹配。

  1.  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魔法与文字魔法不相容。

  1.  attr

在attr:出现空格分隔的“属性要求”列表之后，必须满足所有这些要求才能将路径视为匹配;这是除了通常的非魔术pathpec模式匹配之外。见 gitattributes [5] 。

路径的每个属性要求都采用以下形式之一：

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

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

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

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

    请注意，在对树对象进行匹配时，仍然可以从工作树获取属性，而不是从给定的树对象获取属性。

  1.  exclude

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

  1.  parent

提交对象包含开发线中的逻辑前任（即其父项）的（可能是空的）列表。

  1.  pickaxe

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

  1.  plumbing

核心Git 的可爱名称。

  1.  porcelain

程序和程序套件的可爱名称取决于核心Git ，提供对核心Git的高级访问。与管道相比，瓷器暴露出更多的 SCM 界面。

  1.  per-worktree ref

根据工作树的参考，而不是全局。目前只有 HEAD 以及以refs/bisect/开头的任何引用，但后来可能包括其他不寻常的引用。

  1.  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将起作用。

  1.  pull

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

  1.  push

推动分支意味着从远程存储库获取分支的头部参考，找出它是否是分支的本地头部参考的祖先，并且case，将可以从本地head ref访问的对象和远程存储库中缺失的对象放入远程对象数据库，并更新远程头部ref。如果远程头不是本地磁头的祖先，则推送失败。

  1.  reachable

给定提交的所有祖先都被认为是来自该提交的“可达”。更一般地说，一个对象可以从另一个到达，如果我们可以通过链跟随标签到达另一个到它们标记的任何东西，将提交给他们的父母或树木，将树提交给他们所包含的树木或 blob 。

  1.  rebase

要重新应用从分支到不同基数的一系列更改，并将该分支的头重置为结果。

  1.  ref

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

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

有一些特殊用途的参考不以refs/开头。最值得注意的例子是HEAD。

  1.  reflog

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

  1.  refspec

fetch 和 push 使用“refspec”来描述远程 ref 和本地ref之间的映射。

  1.  remote repository

存储库，用于跟踪同一个项目但位于其他地方。要与遥控器通信，请参阅获取或按。

  1.  remote-tracking branch

ref ，用于跟踪来自另一个存储库的更改。它通常看起来像 refs / remotes / foo / bar （表示它在名为 foo 的遥控器中跟踪一个名为 bar 的分支），并且匹配右边 - 已配置的提取 refspec 的手边。远程跟踪分支不应包含直接修改或对其进行本地提交。

  1.  repository

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

  1.  resolve

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

  1.  revision

commit （名词）的同义词。

  1.  rewind

抛弃部分开发，即将头分配给早期修订版。

  1.  SCM

源代码管理（工具）。

  1.  SHA-1

“安全哈希算法1”;加密哈希函数。在Git的上下文中用作对象名称的同义词。

  1.  shallow clone

通常是浅存储库的同义词，但该短语使其更明确地表示它是通过运行git clone --depth=...命令创建的。

  1.  shallow repository

一个浅存储库有一个不完整的历史，其中一些提交有父母烧灼（换句话说，Git被告知假装这些提交没有父母，即使他们被记录在提交对象中）。当您仅对项目的近期历史感兴趣时，这有时很有用，即使上游记录的真实历史要大得多。通过向 git-clone [1] 提供--depth选项来创建浅存储库，并且可以稍后使用 git-fetch [1] 加深其历史记录。

  1.  stash entry

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

  1.  submodule

存储库，用于保存另一个存储库中的单独项目的历史记录（后者称为 superproject ）。

  1.  superproject

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

  1.  symref

符号引用：它不是包含 SHA-1 id本身，而是格式为 ref：refs / some / thing ，并且在引用时，它递归地取消引用此引用。 HEAD 是symref的主要示例。使用 git-symbolic-ref [1] 命令操纵符号引用。

  1.  tag

refs/tags/命名空间下的 ref 指向任意类型的对象（通常标签指向标签或提交对象）。与头相反，commit命令不会更新标签。 Git标签与Lisp标签无关（在Git的上下文中称为对象类型）。标记最常用于标记提交祖先链中的特定点。

  1.  tag object

包含 ref 的对象指向另一个对象，该对象可以包含类似提交对象的消息。它还可以包含（PGP）签名，在这种情况下，它被称为“签名标记对象”。

  1.  topic branch

一个常规的Git 分支，开发人员用它来识别概念的开发线。由于分支非常容易且便宜，因此通常需要具有若干小分支，每个小分支包含非常明确定义的概念或小的增量但相关的变化。

  1.  tree

工作树或树对象与从属 blob 和树对象（即工作树的存储表示）一起。

  1.  tree object

包含文件名和模式列表的对象以及对关联的blob和/或树对象的引用。 树相当于目录。

  1.  tree-ish (also treeish)

树对象或对象，可以递归地解除引用到树对象。解除引用提交对象产生对应于修订版的顶部目录的树对象。以下是所有树形图： commit-ish ，树对象，指向树对象的标记对象，指向指向标记对象的标记对象到树对象等

  1.  unmerged index

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

  1.  unreachable object

来自分支，标签或任何其他参考的对象不是可到达的。

  1.  upstream branch

合并到相关分支中的默认分支（或者有问题的分支被重新分配到）。它通过分支配置。< name> .remote和branch。< name> .merge。如果 A 的上游分支是起源/ B ，有时我们说“ A 正在追踪起源/ B ”。

  1.  working tree

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

也可以看看

gittutorial [7] ， gittutorial-2 [7] ， gitcvs-migration [7] ， giteveryday [7] ， Git用户手册

GIT

部分 git [1] 套件