Setup and Config
Getting and Creating Projects
Basic Snapshotting
Branching and Merging
Sharing and Updating Projects
Inspection and Comparison
Patching
Debugging
External Systems
Server Admin
Guides
- gitattributes
- Command-line interface conventions
- Everyday Git
- Frequently Asked Questions (FAQ)
- Glossary
- Hooks
- gitignore
- gitmodules
- Revisions
- Submodules
- Tutorial
- Workflows
- All guides...
Administration
Plumbing Commands
- 2.46.1 → 2.47.0 no changes
- 2.46.0 07/29/24
- 2.44.1 → 2.45.2 no changes
- 2.44.0 02/23/24
- 2.43.2 → 2.43.5 no changes
- 2.43.1 02/09/24
- 2.43.0 11/20/23
- 2.39.1 → 2.42.3 no changes
- 2.39.0 12/12/22
- 2.36.1 → 2.38.5 no changes
- 2.36.0 04/18/22
- 2.33.1 → 2.35.8 no changes
- 2.33.0 08/16/21
- 2.30.1 → 2.32.7 no changes
- 2.30.0 12/27/20
- 2.23.1 → 2.29.3 no changes
- 2.23.0 08/16/19
- 2.22.1 → 2.22.5 no changes
- 2.22.0 06/07/19
- 2.21.1 → 2.21.4 no changes
- 2.21.0 02/24/19
- 2.19.1 → 2.20.5 no changes
- 2.19.0 09/10/18
- 2.18.1 → 2.18.5 no changes
- 2.18.0 06/21/18
- 2.15.4 → 2.17.6 no changes
- 2.14.6 12/06/19
- 2.13.7 05/22/18
- 2.12.5 09/22/17
- 2.9.5 → 2.11.4 no changes
- 2.8.6 07/30/17
- 2.7.6 07/30/17
- 2.6.7 05/05/17
- 2.5.6 no changes
- 2.4.12 05/05/17
- 2.3.10 no changes
- 2.2.3 09/04/15
- 2.1.4 no changes
- 2.0.5 12/17/14
描述
- 轮替对象库(alternate object database)
-
通过替代机制, 一个 repository 能够从另一个对象库中继承 object database 的一部分对象, 这被称作“轮替”。
- 裸仓库(bare repository)
-
一个裸仓库通常是一个有适当命名的directory,后缀为`.git`,它没有任何版本控制下的文件的本地检出副本。也就是说,所有通常存在于隐藏的`.git`子目录中的Git管理和控制文件都直接存在于`repository.git`目录中,而没有其他文件存在并被检出。通常,公共仓库的发布者会提供裸仓库。
- 数据对象 (blob object)
-
无类型的对象,比如一个文件的内容。
- 分支 (branch)
-
一个 “分支” 就是一条开发线。 一个分支上最近的提交被称为该分支的顶端。 分支的顶端被引用分支 head 引用,当分支上有更多的开发工作时,它就会向前移动。 一个Git仓库可以跟踪任意数量的分支,但你的工作区只与其中一个分支(“当前(current) ” 或 “检出(checked out)” 分支)相关联,而HEAD指向该分支。
- 缓存 (cache)
-
已过时:索引。
- (提交)链(chain)
-
一个对象的列表,列表中的每个对象都包含对其继承者的引用(例如,一个提交(commit)的继承者可以是其父对象之一)。
- 变更集 (changeset)
-
BitKeeper/cvsps 是指 "提交"。由于 Git 并不存储变化,而是存储状态,所以在Git中使用 “变化集(changesets)” 这个词真的没有意义。
- 检出 (checkout)
- 拣选(cherry-picking)
-
在 SCM 中,"cherry pick" 意味着从一系列的修改(通常是提交)中选择一个子集,并将其记录为不同仓库之上的一系列新修改。在 Git 中,这是由 "git cherry-pick" 命令执行的,提取现有提交引入的修改,并根据当前分支的提示,将其记录为新提交。
- 干净(的工作区)
- 提交
-
作为名词时,意为:Git 历史中的一个点;一个项目的整个历史被表示为一组相互关联的提交。 Git 经常使用 “提交(commit)” 这个词,就像其他版本控制系统使用 "revision" 或 "version" 一样。 也被用作提交对象的简称。
- 提交图示(commit graph)的概念、结构表示和用途
-
由对象数据库中的提交形成的有向无环图(DAG),由被引用的分支提示,使用其对象链(chain)的链接提交。 这个结构就是明确的提交图。该图还有其他展示形式,例如“提交图示” 文件。
- 提交图示(commit-graph)文件
-
“提交图示(ommit-graph)”(通常是连字符)文件是提交图(commit graph)的补充表示,可以加速提交图的生成。“提交图示” 文件存储在 .git/objects/info 目录下,或者存储在另一个对象数据库的 info 目录下。
- 提交对象(commit object)
- 提交号[commit-ish (also committish)]
-
一个提交对象或一个对象可以递归解引用到一个提交对象。提交对象、指向提交对象的标签对象、指向提交对象的标签对象的标签对象,等等。
- Git 核心(core Git)
-
Git 的基本数据结构和实用工具。只暴露了有限的源代码管理工具。
- 有向无环图 (DAG)
-
有向无环图。提交对象形成了一个有向无环图,因为它们有父提交(有向),而且提交对象的图是无环的(没有对象链以同一个对象开始和结束)。
- 悬空对象
- 解引用
-
引用 符号引用:访问符号引用所指向的 引用 的操作。递归解引用是指对结果引用重复上述过程,直到找到非符号引用为止。
引用 标签对象:访问标签指向的 对象 的操作。通过重复对结果对象的操作来递归引用标记,直到结果对象具有指定的 对象类型(如适用)或任何非 “标签” 对象类型。标签中 “递归解引用” 的同义词是“剥离”。
引用 提交对象:访问提交的树对象的操作。提交不能被递归解引用。
除非另有说明,在 Git 命令或协议中使用的 “解引用” 是隐式递归的。
- 分离的头指针(detached HEAD)
-
通常,HEAD 存储的是一个分支的名称,对 HEAD 所代表的历史进行操作的命令会对HEAD所指向的分支的顶端的历史进行操作。然而,Git 也允许你签出到一个任意的提交,不一定是任何特定分支的顶端。处于这种状态的 HEAD 被称为 “分离”。
请注意,当 HEAD 分离时,对当前分支的历史进行操作的命令(例如,
git commit
在其上建立一个新的历史)仍然有效。它们会更新 HEAD,使其指向更新的历史记录的顶端,而不影响任何分支。更新或查询关于当前分支的信息的命令(例如,git branch --set-upstream-to
,设置当前分支与哪个远程跟踪分支集成)显然不起作用,因为在这种状态下没有(真正的)当前分支可以查询。 - 目录
-
你用 "ls" 命令得到的列表 :-)
- 脏(的工作区)(dirty)
- 坏合并(合并引入了父提交没有的修改)(evil merge)
- 快速合并
-
快速合并是合并的一种特殊类型,即你有一个版本而你正在“合并”另一个分支的修改,这些修改恰好是你的后续提交。在这种情况下,你不需要添加一个新的合并 提交而只是更新你的分支,使其指向与你要合并的分支相同的版本。这种情况会经常发生在一个远程远程跟踪分支的仓库。
- 获取(fetch)
-
获取一个分支意味着从远程仓库获取该分支的头引用,找出本地对象库中缺失的对象,并获取这些对象。另见 git-fetch[1]。
- 文件系统
-
Linus Torvalds (林纳斯·本纳第克特·托瓦兹;Git的作者、Linux之父)最初将 Git 设计为用户空间文件系统,即用于保存文件和目录的基础结构。这确保了 Git 的效率和速度。
- 仓库(对于 arch 用户)(Git archive)
-
与仓库 同义(对于arch用户)。
- gitfile(仓库链接文件)
-
工作目录树根目录下的普通文件
.git
,指向真正的仓库目录。正确用法参见 git-worktree[1] 或 git-submodule[1]。语法参见 gitrepository-layout[5]。 - (提交)移植(grafts)
-
移植(Grafts)通过记录提交的虚假祖先信息,使两条原本不同的开发线连接在一起。这样你就可以让 Git 假装提交的一组父提交与创建提交 (commit) 时的记录不同。通过
.git/info/grafts
文件进行配置。请注意,移植 (Grafts) 机制已经过时了,可能会导致在仓库之间转移对象的问题;参见 git-replace[1] ,这是一个更灵活更强大的系统,可以做同样的事情。
- 哈希(hash)
-
在 Git 的上下文中,是对象名称的同义词。
- 头/分支(head)
-
一个命名引用到提交在分支的顶端。头部存储在
$GIT_DIR/refs/heads/
目录下的一个文件中,除非使用打包的引用(参见 git-pack-refs[1]。) - HEAD(头指针,亦即当前分支)
-
当前分支。详细地讲,你的工作区通常是由 HEAD 所指的树的状态衍生出来的。HEAD 是对你的版本库中的一个头的引用,除非使用分离的 HEAD,这种情况下它直接引用一个任意的提交。
- 头引用
-
头的同义词。
- 钩子
-
在几个 Git 命令的正常执行过程中,会对可选的脚本进行调用,允许开发者添加功能或检查。通常情况下,钩子允许一个命令被预先验证并可能中止执行,并允许在操作完成后发出通知。钩子脚本可以在
$GIT_DIR/hooks/
目录下找到,只需将文件名中的.sample
后缀去掉即可启用。在早期版本的 Git 中,你必须将它们设置为可执行。 - 索引
-
一个带有统计信息的文件集合,其内容以对象形式存储。索引是你的工作区的一个存储版本。事实上它也可以包含第二个,甚至第三个版本的工作区,这些在合并时使用。
- 索引项
-
关于某个特定文件的信息,存储在索引/暂存区。如果合并已经开始,但尚未完成(即如果索引包含该文件的多个版本),则索引条目可以取消合并。
- master(默认分支名)
-
默认的开发分支 。每当你创建一个 Git 仓库,就会创建一个名为 "master" 的分支,并成为活动分支。在大多数情况下,它包含了本地的开发内容,但这纯粹是惯例,并不是必须的。
- 合并
-
作为动词。将另一个分支(可能来自外部仓库)的内容引入当前分支。在被合并的分支来自不同的仓库的情况下,这是通过首先抓取远程分支,然后将结果合并到当前分支来实现的。这种获取和合并操作的组合被称为拉取。合并是由一个自动过程进行的,该过程会识别自分支分歧以来的变化,然后将所有这些变化应用在一起。在变化发生冲突的情况下,可能需要人工干预来完成合并。
- 对象
-
Git中的存储单位。它由其内容的SHA-1作为唯一的标识。因此,一个对象不能被改变。
- 对象库
-
存储一组 “对象 (objects)”,一个单独的对象由其对象名称标识。这些对象通常存在于`$GIT_DIR/objects/`中。
- 对象标识符 [object identifier (oid)]
-
对象名称的同义词。
- 对象名称
- 对象类型
- 章鱼式合并(两分支以上的合并)(octopus)
- orphan(孤儿分支)
- origin(默认的远程名称)
-
默认的上游仓库。大多数项目至少有一个上游项目,它们会对其进行跟踪。默认情况下,origin 被用于此目的。新的上游更新会被拉取到远程跟踪分支,名为 origin/name-of-upstream-branch,你可以用
git branch -r
看到。 - 覆盖 (overlay)
-
只更新和添加文件到工作目录,但不删除它们,类似于 cp -R 会更新目标目录中的内容。这是检出中的默认模式,当从暂存区或树状标识中检出文件时。相反,非覆盖模式也会删除源文件中不存在的跟踪文件,类似于 rsync --delete。
- 包 (pack)
-
一组被压缩成一个文件的对象(以节省空间或有效传输)。
- 包索引 (pack index)
-
包中的对象的标识符和其他信息的列表,以协助有效地访问一个包的内容。
- 路径规范 (pathspec)
-
用来限制 Git 命令中的路径的模式。
在 "git ls-files"、"git ls-tree"、"git add"、"git grep"、"git diff"、"git checkout" 和许多其他命令的命令行中,路径规格被用来将操作范围限制在树或工作区的某个子集。 关于路径是相对于当前目录还是顶层,请参阅每个命令的文档。 路径规范的语法如下:
-
任何路径都与自己匹配
-
到最后一个斜线的路径规范代表一个目录前缀。 该路径规范的范围只限于该子树。
-
路径规范的其余部分是路径名其余部分的模式。 相对于目录前缀的路径将使用fnmatch(3)(匹配函数)与该模式进行匹配;特别是,* 和 ? 可以 匹配目录分隔符。
例如,Documentation/*.jpg 将匹配 Documentation 子目录中的所有 .jpg 文件,包括 Documentation/chapter_1/figure_1.jpg。
以冒号
:
开头的路径规范有特殊含义。 在简短的形式中,前面的冒号:
后面是 0 个或更多的 “魔术签名(magic signature)”(可以选择以另一个冒号:
结束),剩下的部分是与路径匹配的模式。 “魔术签名” 由ASCII符号组成,这些符号既不是字母数字、通配符、正则表达式特殊字符也不是冒号。 如果模式以不属于 “魔术签名” 符号集的字符开始,并且不是冒号,那么结束 “魔术签名” 的可选冒号就可以省略。在较长规范中,前面的冒号
:
后面是一个开放的小括号(
,一个用逗号分隔的 0 个或多个 “魔术单词” 列表,以及一个封闭的小括号)
,其余部分是要与路径匹配的模式。一个只有冒号的路径规范意味着 “不使用路径规范”。这种形式不应该与其他路径规范结合。
- 顶部 (top)
-
魔术词
top
(魔术签名:/
)使模式从工作区的根目录开始匹配,即使你从子目录内运行命令。 - 字面量 (literal)
-
模式中的通配符,如
*
或?
被视为字面量字符。 - 不敏感匹配 (icase)
-
不区分大小写的匹配。
- 通配符
-
Git 将模式视为适合 fnmatch(3)(匹配函数)使用 shell 的通配符模式(shell 所使用的简化了的正则表达式),带有FNM_PATHNAME 标志:模式中的通配符将不匹配路径名中的 /(即不对子目录或上级目录进行匹配)。例如,"Documentation/*.html" 匹配 "Documentation/git.html",而不是 "Documentation/ppc/ppc.html" 或 "tools/perf/Documentation/perf.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)
-
一个提交对象包含一个开发中的逻辑前驱列表(可能是空的),即其父提交。
- 剥离 (peel)
- 挖掘 (pickaxe)
-
术语挖掘指的是 diff 核心例程 (diffcore) 的一个选项,辅助选择增加或删除特定文本字符串的变化。通过
--pickaxe-all
选项,它可以用来查看引入或删除的全部变更集,例如某一行文字。参见 git-diff[1]。 - 管件 (plumbing)
-
Git 核心的昵称。
- 瓷件 (porcelain)
- 工作区引用(per-worktree ref)
-
相比于全局引用,它是对每个工作区的引用。 目前只有 HEAD 和任何以
refs/bisect/
开头的引用,但以后可能包括其他不寻常的引用。 - 伪引用 (pseudoref)
-
A ref that has different semantics than normal refs. These refs can be read via normal Git commands, but cannot be written to by commands like git-update-ref[1].
The following pseudorefs are known to Git:
-
FETCH_HEAD
is written by git-fetch[1] or git-pull[1]. It may refer to multiple object IDs. Each object ID is annotated with metadata indicating where it was fetched from and its fetch status. -
MERGE_HEAD
is written by git-merge[1] when resolving merge conflicts. It contains all commit IDs which are being merged.
-
- 拉取 (pull)
-
拉取一个分支意味着获取一个分支并且合并这个分支。 另见 git-pull[1]。
- 推送 (push)
-
推送一个分支意味着从远程的仓库获取该分支的头引用,找出它是否是该分支的本地分支引用的一个祖先。在这种情况下,将所有从本地分支引用可达的对象,以及从远程仓库中丢失的对象,放入远程对象库,并更新远程分支引用。如果远程头/分支不是本地分支的祖先,则推送失败。
- 可达的 (reachable)
-
一个给定的提交的所有祖先都被称为可以从该提交 “到达”。更一般地说,如果一个对象可以通过对象链从一个标签到达任意一个对象链标记的标签,那么该对象就是可达的,提交到它们的父提交或树,以及树到它们所包含的树或二进制对象。
- 可达性位图
-
可达性位图存储了包文件或多包索引(MIDX)中选定的一组提交的可达性的信息,以加快对象搜索。 位图被存储在 ".bitmap" 文件中。一个仓库最多可以有一个位图文件在使用。这个位图文件可以属于一个包,也可以属于仓库的多包索引(如果有的话)。
- 变基 (rebase)
- 引用 (ref)
-
A name that points to an object name or another ref (the latter is called a symbolic ref). For convenience, a ref can sometimes be abbreviated when used as an argument to a Git command; see gitrevisions[7] for details. Refs are stored in the repository.
引用名称空间是分层的。引用名称必须以
refs/
开头,或者位于层次结构的根目录中。对于后者,它们的名称必须遵循以下规则:-
名称仅由大写字母或下划线组成。
-
名称以"
_HEAD
"结尾,或者等于"HEAD
"。在层次结构根目录中存在一些不符合这些规则的非正规引用。以下列表详细得列出了所有情况并不会继续扩展:
-
AUTO_MERGE
-
BISECT_EXPECTED_REV
-
NOTES_MERGE_PARTIAL
-
NOTES_MERGE_REF
-
MERGE_AUTOSTASH
Different subhierarchies are used for different purposes. For example, the
refs/heads/
hierarchy is used to represent local branches whereas therefs/tags/
hierarchy is used to represent local tags..
-
- 引用日志 (reflog)
-
引用日志显示一个引用的本地 “历史”。 换句话说,它可以告诉你,在昨天下午 9:14,这个 仓库的最后三次修订是什么,以及 这个 仓库的当前状态是什么。 详情见 git-reflog[1]。
- 引用规范 (refspec)
-
A "refspec" is used by fetch and push to describe the mapping between remote ref and local ref. See git-fetch[1] or git-push[1] for details.
- 远程仓库 (remote repository)
- 远程跟踪分支 (remote-tracking branch)
-
一个用来跟踪另一个仓库变化的引用。它通常看起来像’refs/remotes/foo/bar'(表示它跟踪一个名为’foo’的远程中名为’bar’的分支),并对配置好的fetch引用规范右侧进行匹配。一个远程跟踪分支不应该由直接的修改或是本地的提交构成。
- 仓库 (repository)
-
一个引用的集合和一个对象库的集合,包含了引用中所有的可达的对象,可能还有一个或多个瓷件元数据。一个仓库可以通过轮替对象库与其他存储库共享对象数据库。
- 解决 (resolve)
-
手动修复由自动合并产生的遗留错误。
- 版本 (revision)
-
与提交(名词形式)同义。
- 回退 (rewind)
- SCM(源代码管理工具)
-
源代码管理(工具)。
- SHA-1
-
“安全哈希算法 1”;一个加密哈希函数。 在 Git 的上下文中是对象名的同义词。
- 浅克隆 (shallow clone)
-
大部分是指浅仓库,但它更明确地表明其是通过运行
git clone --depth=...
命令创建的。 - 浅仓库 (shallow repository)
-
一个浅仓库不会记录完整的提交历史,其中一些提交的父提交被销毁了(换句话说,Git 被告知假装这些提交没有父提交,尽管在提交对象中有记录)。当你只对一个项目的近期历史感兴趣时,这是很有用的,尽管上游记录的真实历史要大得多。通过给 git-clone[1]提供
--depth
选项,可以创建一个浅层的仓库,之后可以用 git-fetch[1] 深掘它的历史。 - 贮藏项 (stash entry)
- 子模块 (submodule)
- 父工程 (superproject)
- 符号引用 (symref)
-
符号引用:它本身不包含 SHA-1 ID,而是采用 ref: refs/some/thing 的格式,当被引用时,它会递归 解引用 到该引用。HEAD 就是符号引用的一个典型例子。符号引用可以通过 git-symbolic-ref[1] 命令来操作。
- 标签 (tag)
-
在
refs/tags/
命名空间下的一个引用,指向一个任意类型的对象(通常一个标签指向一个标签对象或者一个提交对象)。 与head标记相比,标签不会被commit
命令更新。Git 的标签与 Lisp 的标签(在Git的上下文中称为对象类型)毫无关系。标签最常用的是标记祖先提交中的一个特定对象链。 - 标签对象 (tag object)
-
一个对象包含一个指向另一个对象的引用,它可以像提交对象那样包含一个消息。它也可以包含一个(PGP)签名,这种情况下 PGP 被称为: “有签名的标签对象” (signed tag object)。
- 主题分支 (topic branch)
-
一个常规的 Git 分支,被开发者用来确定一个概念性的开发路线。由于新建一个分支通常需要很小的代价,所以通常开发中会包含几个小的分支,每个分支都有着非常明确的概念或小的增量但相关的变化。
- 树/目录树 (tree)
- 树对象 (tree object)
- 树状标识 [tree-ish (also treeish)]
-
一个 目录树对象 或一个 object 可以递归 解引用 到一个目录树对象。解引用 提交对象 可以得到与 修订 的顶层 目录 相对应的目录树对象。以下都是树状对象:一个 提交号、一个树状对象、一个指向树状对象的 标签对象、一个指向树状对象的标签对象、一个指向目录树对象的标签对象,等等。
- 未出现(unborn)
-
HEAD 可以指向一个分支,而这个分支>尚未存在,也没有任何提交,这样的分支被称为未诞生分支。用户遇到未诞生分支的最常见方式是不从其他地方克隆,而是重新创建一个仓库。HEAD 会指向尚未诞生的 main(或 master,取决于你的配置)分支。此外,某些操作也会通过 <<def_orphan,orphan 选项让你进入一个未诞生的分支。
- 未合并暂存区 (unmerged index)
- 不可达对象 (unreachable object)
- 上游分支 (upstream branch)
-
默认的 分支 会被合并到相关的分支中(或相关的变基 (rebase) 分支)。它是通过
branch.<name>.remote
和branch.<name>.merge
配置的。如果 A 的上游分支是 origin/B,这有时会称作 “A 正在跟踪 origin/B”。 - 工作区 (working tree)
-
实际检查出来的文件树。 工作区通常包含HEAD提交树的内容,和一些你已经做了但还没有提交的本地修改。
- 工作树(worktree)
-
一个仓库可以没有(即裸仓库),也可以有一个或多个工作树附属于它。一个 “工作树 ”由 “工作区”和版本库元数据组成,其中大部分元数据在单个仓库的其他工作树中共享,有些元数据在每个工作树中单独维护(例如:索引、HEAD 和像MERGE_HEAD这样的伪引用 、每个工作树索引件和每个工作树)。
GIT
属于 git[1] 文档