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_HEADCHERRY_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

fetchpush 使用“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] 套件