Git
简体中文 ▾ Topics ▾ Latest version ▾ gitglossary last updated in 2.43.0

名称

gitglossary - Git术语表

概述

*

描述

轮替对象库(alternate object database)

通过替代机制, 一个 repository 能够从另一个对象库中继承 object database 的一部分对象, 这被称作“轮替”。

裸仓库(bare repository)

一个裸仓库通常是一个有适当命名的directory,后缀为`.git`,它没有任何版本控制下的文件的本地检出副本。也就是说,所有通常存在于隐藏的`.git`子目录中的Git管理和控制文件都直接存在于`repository.git`目录中,而没有其他文件存在并被检出。通常,公共仓库的发布者会提供裸仓库。

数据对象 (blob object)

无类型的对象,比如一个文件的内容。

分支 (branch)

一个 "分支 "就是一条开发线。 一个分支上最近的commit被称为该分支的顶端。 分支的顶端被引用分支head引用,当分支上有更多的开发工作时,它就会向前移动。 一个Git仓库可以跟踪任意数量的分支,但你的工作区只与其中一个分支("当前(current) "或 "检出(checked out)"分支)相关联,而头指针指向该分支。

缓存 (cache)

已过时:[def_index,索引]

(提交)链(chain)

一个对象的列表,列表中的每个对象都包含对其继承者的引用(例如,一个提交(commit)的继承者可以是其父对象之一)。

变更集 (changeset)

BitKeeper/cvsps是指"提交"。由于Git并不存储变化,而是存储状态,所以在Git中使用"变化集(changesets)"这个词真的没有意义。

检出 (checkout)

对象库中的树对象blob更新全部或部分工作区,如果整个工作树已经指向一个新分支,就更新暂存区头指针

拣选(cherry-picking)

SCM中,"cherry pick"意味着从一系列的修改(通常是提交)中选择一个子集,并将其记录为不同代码库之上的一系列新修改。在Git中,这是由"git cherry-pick"命令执行的,提取现有提交引入的修改,并根据当前分支的提示,将其记录为新提交。

干净(的工作区)

如果一个工作区对应于当前版本所引用的头、分支,它就是干净的(clean)。另请参见"脏(的工作区)"。

提交

作为名词时,意为:Git 历史中的一个点;一个项目的整个历史被表示为一组相互关联的提交。 Git经常使用"提交(commit)"这个词,就像其他版本控制系统使用"revision"或"version"一样。 也被用作提交对象的简称。

作为动词时,意为:在 Git 历史中存储一个该项目状态的新快照,通过创建一个代表当前暂存区状态的提交,并移动头指针指向此新提交。

提交图示(commit graph)的概念、结构表示和用途

由对象数据库中的提交形成的有向无环图(DAG),由被引用的分支提示,使用其对象链(chain)的链接提交。 这个结构就是明确的提交图。该图还有其他展示形式,例如"提交图示"文件

提交图示(commit-graph)文件

“提交图示(ommit-graph)”(通常是连字符)文件是提交图(commit graph)的补充表示,可以加速提交图的生成。“提交图示”文件存储在.git/objects/info目录下,或者存储在另一个对象数据库的info目录下。

提交对象(commit object)

一个对象 包含了关于某个特定版本的信息,例如父提交、提交者、作者、日期和树对象(对应于保存的版本顶部目录)。

提交号[commit-ish (also committish)]

一个提交对象或一个对象可以递归反向引用到一个提交对象。这些都与提交号(commit-ish)有关:提交对象、指向提交对象的标签对象、指向,指向提交对象的标签对象,的标签对象,等等。

Git核心(core Git)

Git 的基本数据结构和实用工具。只暴露了有限的源代码管理工具。

有向无环图(DAG)

有向无环图。提交对象形成了一个有向无环图,因为它们有父提交(有向),而且提交对象的图是无环的(没有对象链以同一个对象开始和结束)。

悬空对象

一个不可达对象,即使从其他无法可达对象也无法可达;一个悬空对象在仓库中没有任何引用或对象

[[def_detached_HEAD]分离的头指针(detached HEAD)

通常,HEAD存储的是一个分支的名称,对 HEAD 所代表的历史进行操作的命令会对HEAD所指向的分支的顶端的历史进行操作。然而,Git 也允许你签出到一个任意的提交,不一定是任何特定分支的顶端。处于这种状态的 HEAD 被称为“分离”。

请注意,当 HEAD 分离时,对当前分支的历史进行操作的命令(例如,git commit`在其上建立一个新的历史)仍然有效。它们会更新 HEAD,使其指向更新的历史记录的顶端,而不影响任何分支。更新或查询关于当前分支的信息的命令(例如,`git branch --set-upstream-to,设置当前分支与哪个远程跟踪分支集成)显然不起作用,因为在这种状态下没有(真正的)当前分支可以查询。

目录

你用 "ls" 命令得到的列表(─‿‿─)

脏(的工作区)(dirty)

如果工作区包含的修改没有被提交到当前的分支,就被认为是 "dirty" 的。

坏合并(合并引入了父提交没有的修改)(evil merge)

一个坏合并,指引入了没有出现在任何父提交中修改的合并

快速合并

快速合并是合并的一种特殊类型,即你有一个版本而你正在“合并”另一个分支的修改,这些修改恰好是你的后续提交。在这种情况下,你不需要添加一个新的合并 提交而只是更新你的分支,使其指向与你要合并的分支相同的版本。这种情况会经常发生在一个远程远程跟踪分支仓库

获取(fetch)

获取一个分支意味着从远程仓库获取该分支的头引用,找出本地对象库中缺失的对象,并获取这些对象。另见 git-fetch[1]

文件系统

Linus Torvalds (林纳斯·本纳第克特·托瓦兹;Git的作者、Linux之父)最初将 Git 设计为用户空间文件系统,即用于保存文件和目录的基础结构。这确保了 Git 的效率和速度。

仓库(对于arch用户)(Git archive)

仓库 同义(对于arch用户)。

gitfile(仓库链接文件)

在工作区根部的普通文件 .git,指向真正的版本库目录。

(提交)移植(grafts)

Grafts enable two otherwise different lines of development to be joined together by recording fake ancestry information for commits. This way you can make Git pretend the set of parents a commit has is different from what was recorded when the commit was created. Configured via the .git/info/grafts file.

请注意,移植(Grafts)机制已经过时了,可能会导致在仓库之间转移对象的问题;参见 git-replace[1] ,这是一个更灵活更强大的系统,可以做同样的事情。

哈希(hash)

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

头/分支(head)

一个命名引用提交分支的顶端。头部存储在 $GIT_DIR/refs/heads/ 目录下的一个文件中,除非使用打包的 refs(参见 git-pack-refs[1])。

HEAD(头指针,亦即当前分支)

当前分支。详细地讲,你的工作区通常是由 HEAD 所指的树的状态衍生出来的。HEAD 是对你的版本库中的一个的引用,除非使用分离的 HEAD,这种情况下它直接引用一个任意的提交。

头引用

的同义词。

[[def_hook]钩子

在几个 Git 命令的正常执行过程中,会对可选的脚本进行调用,允许开发者添加功能或检查。通常情况下,钩子允许一个命令被预先验证并可能中止执行,并允许在操作完成后发出通知。钩子脚本可以在 $GIT_DIR/hooks/ 目录下找到,只需将文件名中的 .sample 后缀去掉即可启用。在早期版本的 Git 中,你必须将它们设置为可执行。

索引

一个带有统计信息的文件集合,其内容以对象形式存储。索引是你的工作区的一个存储版本。事实上它也可以包含第二个,甚至第三个版本的工作区,这些在合并时使用。

索引项

关于某个特定文件的信息,存储在索引/暂存区。如果合并已经开始,但尚未完成(即如果索引包含该文件的多个版本),则索引条目可以取消合并。

master(默认分支名)

默认的开发分支 。每当你创建一个 Git 仓库,就会创建一个名为 "master" 的分支,并成为活动分支。在大多数情况下,它包含了本地的开发内容,但这纯粹是惯例,并不是必须的。

[[def_merge]合并

作为动词。将另一个分支(可能来自外部仓库)的内容引入当前分支。在被合并的分支来自不同的仓库的情况下,这是通过首先抓取远程分支,然后将结果合并到当前分支来实现的。这种获取和合并操作的组合被称为拉取。合并是由一个自动过程进行的,该过程会识别自分支分歧以来的变化,然后将所有这些变化应用在一起。在变化发生冲突的情况下,可能需要人工干预来完成合并。

作为名词,除非是快速合并,否则一个成功的合并会产生一个新的提交,代表合并的结果,并且有父提交分支 合并的提示。这种提交被称为"合并提交",或者有时只是"合并"。

对象

Git中的存储单位。它由其内容的SHA-1作为唯一的标识。因此,一个对象不能被改变。

[[def_object_database]对象库

存储一组"对象",一个单独的对象由其对象名称标识。这些对象通常存在于`$GIT_DIR/objects/`中。

对象标识符[object identifier (oid)]

对象名称的同义词。

对象名称

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

对象类型

其中一个标识符"提交", "", "标签"或"blob"描述一个<<def_object,对象>的类型。

章鱼式合并(两分支以上的合并)(octopus)

合并两个以上的分支

origin(默认的远程名称)

默认的上游仓库。大多数项目至少有一个上游项目,它们会对其进行跟踪。默认情况下,'origin’被用于此目的。新的上游更新会被拉取到远程跟踪分支,名为origin/name-of-upstream-branch,你可以用`git branch -r`看到。

覆盖(overlay)

只更新和添加文件到工作目录,但不删除它们,类似于’cp -R’会更新目标目录中的内容。这是检出中的默认模式,当从暂存区树对象(tree-ish)中检出文件时。相反,非覆盖模式也会删除源文件中不存在的跟踪文件,类似于’rsync --delete'。

[[def_pack]包(pack)

一组被压缩成一个文件的对象(以节省空间或有效传输)。

包索引(pack index)

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

路径规范(pathspec)

用来限制Git命令中的路径的模式。

在 "git ls-files"、"git ls-tree"、"git add"、"git grep"、"git diff"、"git checkout "和许多其他命令的命令行中,路径规格被用来将操作范围限制在树或工作区的某个子集。 关于路径是相对于当前目录还是顶层,请参阅每个命令的文档。 pathspec的语法如下:

  • 任何路径都与自己匹配

  • 到最后一个斜线的路径规范代表一个目录前缀。 该路径规范的范围只限于该子树。

  • 路径规范的其余部分是路径名其余部分的模式。 相对于目录前缀的路径将使用fnmatch(3)(匹配函数)与该模式进行匹配;特别是,‘*’和‘?’_可以_匹配目录分隔符。

例如,Documentation/*.jpg将匹配Documentation子树中的所有.jpg文件,包括Documentation/chapter_1/figure_1.jpg。

以冒号`:开头的路径规范有特殊含义。 在简短的形式中,前面的冒号:后面是0个或更多的 “魔术签名(magic signature)”(可以选择以另一个冒号:`结束),剩下的部分是与路径匹配的模式。 “魔术签名”由ASCII符号组成,这些符号既不是字母数字、glob、regex特殊字符也不是冒号。 如果模式以不属于“魔术签名”符号集的字符开始,并且不是冒号,那么结束“魔术签名”的可选冒号就可以省略。

在较长规范中,前面的冒号`:后面是一个开放的小括号(,一个用逗号分隔的0个或多个 “魔术单词”列表,以及一个封闭的小括号)`,其余部分是要与路径匹配的模式。

一个只有冒号的路径规范意味着 “不使用路径规范”。这种形式不应该与其他路径规范结合。

顶部(top)

魔术词`top`(魔术签名:/)使模式从工作区的根目录开始匹配,即使你从子目录内运行命令。

字面量(literal)

模式中的通配符,如`*?`被视为字面量字符。

不敏感匹配(icase)

不区分大小写的匹配。

通配符

Git将模式视为适合fnmatch(3)(匹配函数)使用shell的glob模式(shell 所使用的简化了的正则表达式),带有FNM_PATHNAME标志:模式中的通配符将不匹配路径名中的/(即不对子目录或上级目录进行匹配)。例如,"Documentation/*.html"匹配"Documentation/git.html",而不是"Documentation/ppc/ppc.html"或"tools/perf/Documentation/perff.html"。

在与全路径名匹配的模式中,两个连续的星号("**")可能有特殊含义:

  • "**"在带斜杠目录之前,表示在所有目录中匹配。例如,"**/foo"匹配任何文件或目录的"foo",与模式"foo"相同。"**/foo/bar"匹配任何文件或目录中直接位于目录"foo"之下的"bar"。

  • 路径后跟有"/**"表示匹配这个目录里面的所有文件。例如,"abc/**"匹配相对于`.gitignore`文件的位置中目录 "abc "内的所有文件,深度无限。

  • 一个斜杠后面是两个连续的星号再接上一个斜杠,匹配零个或多个目录。例如,"a/**/b" 匹配 "a/b"、"a/x/b"、"a/x/y/b",等等,依此类推。

  • 其他连续的星号是无效的。

    通配符魔术词(glob)与字面量魔术词(literal)是不相容的。

属性匹配

在`attr:` 之后是一个空格分隔的“属性要求”列表,所有这些都必须满足才能被认为是匹配的路径;这是在通常的非魔法路径规范模式匹配之外的。参见gitattributes[5]

以下包含了路径的每个属性要求:

  • "ATTR"表示要求设置`ATTR`属性。

  • "-ATTR"要求属性`ATTR`没有设置。

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

  • "!ATTR"要求属性`ATTR`是未指定的。

    注意,当与树对象进行匹配时,属性仍然是从工作区中获得的,而不是从给定的树对象中获得。

排除匹配(exclude)

当一个路径匹配了任何规则之外的(non-exclude)路径规范后,它将遍历所有的排除性路径规范(魔术签名:!`或其同义词^`)。如果匹配,该路径将被忽略。 当没有规则之外路径规范时,排除法将应用于结果集,就像在没有任何路径规范的情况下调用。

父提交(parent)

一个提交对象包含一个开发中的逻辑前驱列表(可能是空的),即其父提交。

挖掘(pickaxe)

术语挖掘指的是diff核心例程(diffcore)的一个选项,辅助选择增加或删除特定文本字符串的变化。通过`--pickaxe-all`选项,它可以用来查看引入或删除的全部变更集,例如某一行文字。参见git-diff[1]

管件(plumbing)

Git核心的昵称。

瓷件(porcelain)

依靠Git核心的程序和程序套件的昵称,是对Git核心上层封装。与管件相比,瓷件暴露了更多SCM接口。

工作区引用(per-worktree ref)

相比于全局引用,它是对每个工作区的引用。 目前只有HEAD和任何以`refs/bisect/`开头的引用,但以后可能包括其他不寻常的引用。

伪引用(pseudoref)

伪引用是`$GIT_DIR`下的一类文件,其行为与修订-剖析(rev-parse)中的引用一样,但被Git区分对待。 伪引用的名字一般是由由一行SHA-1开始,然后是空格。 所以,HEAD并不是一个伪引用,因为它有时是一个符号性引用。 它可能选择性地包含一些额外的数据。 比如`MERGE_HEAD`和`CHERRY_PICK_HEAD`。 与工作区引用不同,这些文件不能是符号引用,也没有引用日志。 它们也不能通过正常的引用更新机制进行更新。 相反,它们是通过直接写入文件来更新的。 不过,它们可以被当作引用读取,所以 git rev-parse MERGE_HEAD 仍可以运行。

拉取(pull)

拉取一个分支意味着获取一个分支并且合并这个分支。 另见 git-pull[1]

推送(push)

推送一个分支意味着从远程的仓库获取该分支的头引用,找出它是否是该分支的本地分支引用的一个祖先。在这种情况下,将所有从本地分支引用可达的对象,以及从远程仓库中丢失的对象,放入远程对象库,并更新远程分支引用。如果远程头/分支不是本地分支的祖先,则推送失败。

可达的(reachable)

一个给定的提交的所有祖先都被称为可以从该提交 “到达”。更一般地说,如果一个对象可以通过对象链从一个标签到达任意一个对象链标记的标签,那么该对象就是可达的,提交到它们的父提交或树,以及到它们所包含的树或二进制对象

可达性位图

可达性位图存储了包文件或多包索引(MIDX)中选定的一组提交的可达性的信息,以加快对象搜索。 位图被存储在".bitmap "文件中。一个版本库最多可以有一个位图文件在使用。这个位图文件可以属于一个包,也可以属于版本库的多包索引(如果有的话)。

变基(rebase)

分支的一系列修改重新应用于不同的分支上,并将指针重置为该分支。

引用(ref)

一个以`refs/开头的名字(例如`refs/heads/master),它指向一个对象名称或另一个引用(后者被称为符号引用)。 为方便起见,当作为 Git 命令的参数时,引用可以使用缩写;参见 gitrevisions[7] 。 引用保存在仓库中。

引用的命名空间是分层次的。 不同的子层次表示不同的情况(例如,`refs/heads/`层次用于代表本地分支)。

有一些特殊意义的引用不以`refs/开头。 最经典的例子就是`HEAD

引用日志(reflog)

引用日志显示一个引用的本地 "历史"。 换句话说,它可以告诉你,在昨天下午9:14,_这个_版本库的最后三次修订是什么,以及_这个_版本库的当前状态是什么。 详情见 git-reflog[1]

引用规范(refspec)

“引用规范”是获取推送用以描述远程引用和本地引用之间的映射关系。

远程仓库

一个部署在其他地方但用于跟踪同一个项目的仓库。要与远程通信,请参阅获取推送

远程跟踪分支(remote-tracking branch)

一个用来跟踪另一个仓库变化的引用。它通常看起来像’refs/remotes/foo/bar'(表示它跟踪一个名为’foo’的远程中名为’bar’的分支),并对配置好的fetch引用规范右侧进行匹配。一个远程跟踪分支不应该由直接的修改或是本地的提交构成。

[[def_repository]仓库

一个引用的集合和一个对象库的集合,包含了引用中所有的可达的对象,可能还有一个或多个瓷件元数据。一个仓库可以通过轮替对象库与其他存储库共享对象数据库。

解决

手动修复由自动合并产生的遗留错误。

版本

提交(名词形式)同义。

回退

删除一部分数据,即把指针指向较早的版本

SCM(源代码管理工具)

源代码管理(工具)。

SHA-1

"安全哈希算法1";一个加密哈希函数。 在Git的上下文中是对象名的同义词。

浅克隆(shallow clone)

大部分是指浅仓库,但它更明确地表明其是通过运行`git clone --depth=…​`命令创建的。

[[def_shallow_repository]浅仓库(shallow repository)

一个浅仓库不会记录完整的提交历史,其中一些提交提交被销毁了(换句话说,Git被告知假装这些提交没有父提交,尽管在提交对象中有记录)。当你只对一个项目的近期历史感兴趣时,这是很有用的,尽管上游记录的真实历史要大得多。通过给 git-clone[1]提供 --depth 选项,可以创建一个浅层的仓库,之后可以用 git-fetch[1] 深掘它的历史。

贮藏项

一个对象,用于临时存储工作目录的内容和索引,以便将来重新使用。

子模块(submodule)

一个仓库保存着另一个库内的独立项目的历史(后者被称为父工程)。

父工程(superproject)

一个仓库在其工作区中引用其他项目的仓库,作为子模块。 父工程包含子模块的提交对象的名称(但不持有其副本)。

符号引用

符号引用:它不包含SHA-1id,而是采用’ref: refs/some/thing’的格式,当被引用时,它会递归到这个引用。'HEAD'是一个符号引用的典型例子。符号引用可通过git-symbolic-ref[1]命令对其进行操作。

标签(tag)

在`refs/tags/`命名空间下的一个引用,指向一个任意类型的对象(通常一个标签指向一个标签对象或者一个提交对象)。 与head标记相比,标签不会被`commit`命令更新。Git的标签与Lisp的标签(在Git的上下文中称为对象类型)毫无关系。标签最常用的是标记祖先提交中的一个特定对象链

标签对象

一个对象包含一个指向另一个对象的引用,它可以像提交对象那样包含一个消息。它也可以包含一个(PGP)签名,这种情况下PGP被称为: "有签名的标签对象"(signed tag object)。

主题分支

一个常规的 Git 分支,被开发者用来确定一个概念性的开发路线。由于新建一个分支通常需要很小的代价,所以通常开发中会包含几个小的分支,每个分支都有着非常明确的概念或小的增量但相关的变化。

树/目录树(tree)

要么是一个工作区,要么是一个树对象连同附属的二进制文件对对象和对象树(即一个工作区的存储表示)。

树对象

一个对象包含一个文件名和模式的列表,以及相关的二进制文件和/或对象树的引用。一个等同于一个目录

树状对象[tree-ish (also treeish)]

一个树对象或者一个对象可以递归推断出一个树状对象。 递归一个提交对象可以得到对应于版本的顶层目录树。 以下都是树状对象:提交号、树对象、指向树对象的标签对象、指向树对象标签对象的标签对象,等等。

[[def_unmerged_index]未合并暂存区

一个暂存区,包含未合并的索引项

不可达对象(unreachable object)

一个从分支标签或任何其他引用中都不可达的对象

上游分支

默认的 分支 会被合并到相关的分支中(或相关的变基(rebase)分支)。它是通过 branch.<name>.remotebranch.<name>.merge 配置的。如果’A’的上游分支是’origin/B',这有时会称作“A’正在跟踪’origin/B”。

工作区(working tree)

实际检查出来的文件树。 工作区通常包含HEAD提交树的内容,和一些你已经做了但还没有提交的本地修改。

工作树(worktree)

一个仓库可以没有(即裸仓库),也可以有一个或多个工作树附属于它。一个 “工作树 ”由 “工作区”和版本库元数据组成,其中大部分元数据在单个仓库的其他工作树中共享,有些元数据在每个工作树中单独维护(例如:索引、HEAD 和像MERGE_HEAD这样的伪引用 、每个工作树索引件和每个工作树)。

参见

gittutorial[7], gittutorial-2[7], gitcvs-migration[7], giteveryday[7], link:user-manual.html [Git 用户手册]

GIT

属于 git[1] 文档

scroll-to-top