设置和配置
获取和创建项目
基本快照
分支和合并
共享和更新项目
检查和比较
修补
调试
邮件
外部系统
服务器管理
指南
管理
管道命令
- 2.45.1 → 2.47.0 无更改
- 2.45.0 04/29/24
- 2.44.1 → 2.44.2 无更改
- 2.44.0 02/23/24
- 2.43.2 → 2.43.5 无更改
- 2.43.1 02/09/24
- 2.43.0 11/20/23
- 2.39.1 → 2.42.3 无更改
- 2.39.0 12/12/22
- 2.25.1 → 2.38.5 无更改
- 2.25.0 01/13/20
- 2.24.1 → 2.24.4 无更改
- 2.24.0 11/04/19
- 2.22.1 → 2.23.4 无更改
- 2.22.0 06/07/19
- 2.20.1 → 2.21.4 无更改
- 2.20.0 12/09/18
- 2.18.1 → 2.19.6 无更改
- 2.18.0 无更改
- 2.17.0 → 2.17.6 无更改
- 2.16.6 12/06/19
- 2.15.4 12/06/19
- 2.13.7 → 2.14.6 无更改
- 2.12.5 09/22/17
- 2.11.4 无更改
- 2.10.5 09/22/17
- 2.7.6 → 2.9.5 无更改
- 2.6.7 05/05/17
- 2.5.6 05/05/17
- 2.2.3 → 2.4.12 无更改
- 2.1.4 12/17/14
- 2.0.5 12/17/14
描述
Git 仓库有两种不同的形式
-
工作树根目录下的
.git
目录; -
一个
<project>.git
目录,它是一个裸仓库(即没有它自己的工作树),通常用于通过推送到它和从它中提取来与其他人交换历史记录。
注意:您也可以在工作树的根目录中拥有一个纯文本文件 .git
,其中包含 gitdir: <path>
以指向包含仓库的实际目录。这种机制称为gitfile,通常由 git submodule
和 git worktree
命令管理。它通常用于子模块签出的工作树,以便您在包含的超项目中 git checkout
一个没有子模块的分支。checkout
必须删除整个子模块工作树,而不会丢失子模块仓库。
这些东西可能存在于 Git 仓库中。
- objects
-
与该仓库关联的对象存储。通常,对象存储是自包含的(即,在其中找到的对象引用的所有对象也在其中找到),但是有几种方法可以违反它。
-
您可以通过创建浅克隆来拥有一个不完整但可在本地使用的仓库。请参阅 git-clone[1]。
-
您可以使用
objects/info/alternates
或$GIT_ALTERNATE_OBJECT_DIRECTORIES
机制从其他对象存储借用对象。具有这种不完整对象存储的仓库不适合使用哑传输发布,但只要objects/info/alternates
指向它借用的对象存储,就可以使用它。其他情况下则可以正常使用。如果设置了 $GIT_COMMON_DIR,则忽略此目录,并将使用 "$GIT_COMMON_DIR/objects" 代替。
-
- objects/[0-9a-f][0-9a-f]
-
新创建的对象存储在它自己的文件中。使用 sha1 对象名称的前两个字符将对象分布到 256 个子目录中,以将
objects
本身的目录条目数量保持在可管理的范围内。此处找到的对象通常称为未打包(或松散)对象。 - objects/pack
-
包(以压缩形式存储许多对象的文件,以及索引文件以允许它们被随机访问)位于此目录中。
- objects/info
-
有关对象存储的其他信息记录在此目录中。
- objects/info/packs
-
该文件用于帮助哑传输发现此对象存储中有哪些包。每当添加或删除包时,如果仓库发布用于哑传输,则应运行
git update-server-info
以使此文件保持最新。git repack 默认执行此操作。 - objects/info/alternates
-
该文件记录了此对象存储借用对象的备用对象存储的路径,每行一个路径名。请注意,不仅本地 Git 工具使用它,而且 HTTP 提取器也会尝试远程使用它;如果您在备用文件中使用相对路径(相对于对象数据库,而不是相对于仓库!),这通常会起作用,但如果您使用绝对路径,则不会起作用,除非文件系统和 Web URL 中的绝对路径相同。另请参阅
objects/info/http-alternates
。 - objects/info/http-alternates
-
该文件记录了此对象存储借用对象的备用对象存储的 URL,在通过 HTTP 提取仓库时使用。
- refs
-
引用存储在此目录的子目录中。git prune 命令知道如何保留从在此目录及其子目录中找到的引用中访问的对象。如果设置了 $GIT_COMMON_DIR,则忽略此目录(除了 refs/bisect、refs/rewritten 和 refs/worktree),并将使用 "$GIT_COMMON_DIR/refs" 代替。
- refs/heads/
name
-
记录分支
name
的树顶提交对象 - refs/tags/
name
-
记录任何对象名称(不一定是提交对象,或指向提交对象的标签对象)。
- refs/remotes/
name
-
记录从远程仓库复制的分支的树顶提交对象。
- refs/replace/
<obj-sha1>
-
记录替换
<obj-sha1>
的对象的 SHA-1。这类似于 info/grafts,并且在内部由 git-replace[1] 使用和维护。这些引用可以在仓库之间交换,而 grafts 则不行。 - packed-refs
-
以更有效的方式记录与 refs/heads/、refs/tags/ 及其朋友记录的相同信息。请参阅 git-pack-refs[1]。如果设置了 $GIT_COMMON_DIR,则忽略此文件,并将使用 "$GIT_COMMON_DIR/packed-refs" 代替。
- HEAD
-
指向
refs/heads/
命名空间的 symref(请参阅词汇表),描述当前活动的分支。如果仓库没有与任何工作树关联(即裸仓库),它就没有太大意义,但有效的 Git 仓库必须具有 HEAD 文件;一些瓷器可能使用它来猜测仓库的指定“默认”分支(通常是master)。如果命名分支name 不(尚未)存在,这是合法的。在某些遗留设置中,它是一个符号链接而不是一个 symref,它指向当前分支。HEAD 也可以直接记录特定提交,而不是作为 symref 指向当前分支。这种状态通常称为分离的 HEAD。请参阅 git-checkout[1] 以了解详细信息。
- config
-
仓库特定的配置文件。如果设置了 $GIT_COMMON_DIR,则忽略此文件,并将使用 "$GIT_COMMON_DIR/config" 代替。
- config.worktree
-
在多个工作目录设置中(请参阅 git-worktree[1])的主工作目录的工作目录特定配置文件。
- branches
-
一种略微过时的存储简写的方法,用于指定用于 git fetch、git pull 和 git push 的 URL。可以在
branches/<name>
中存储一个文件,然后在这些命令中使用 name 代替 repository 参数。请参阅 git-fetch[1] 中的 REMOTES 部分以了解详细信息。这种机制是遗留的,不太可能在现代仓库中找到。如果设置了 $GIT_COMMON_DIR,则忽略此目录,并将使用 "$GIT_COMMON_DIR/branches" 代替。 - hooks
-
钩子是各种 Git 命令使用的自定义脚本。当运行git init时,会安装一些示例钩子,但默认情况下它们都是禁用的。要启用,必须通过重命名从文件名中删除
.sample
后缀。阅读 githooks[5] 以了解有关每个钩子的更多详细信息。如果设置了 $GIT_COMMON_DIR,则会忽略此目录,并将使用 "$GIT_COMMON_DIR/hooks" 代替。 - common
-
当使用多个工作树时,$GIT_DIR 中的大多数文件都是每个工作树的,但也有一些已知的例外。但是,common 下的所有文件将在所有工作树之间共享。
- index
-
存储库的当前索引文件。它通常不会出现在裸存储库中。
-
共享索引部分,将由 $GIT_DIR/index 和其他临时索引文件引用。仅在拆分索引模式下有效。
- info
-
存储库的附加信息记录在此目录中。如果设置了 $GIT_COMMON_DIR,则会忽略此目录,并将使用 "$GIT_COMMON_DIR/info" 代替。
- info/refs
-
此文件帮助哑传输发现此存储库中有哪些引用。如果存储库是为哑传输发布的,则每次创建或修改标签或分支时,都应通过git update-server-info重新生成此文件。这通常是在
hooks/update
钩子中完成的,该钩子由git-receive-pack命令在您git push到存储库时运行。 - info/grafts
-
此文件记录伪造的提交祖先信息,以假装提交的父集与实际创建提交的方式不同。每行一个记录描述了一个提交及其伪造的父级,方法是列出它们的 40 字节十六进制对象名称,用空格分隔并以换行符结尾。
请注意,移植机制已过时,会导致在存储库之间传输对象时出现问题;请参阅 git-replace[1] 了解更灵活、更强大的系统来执行相同的操作。
- info/exclude
-
此文件按照 Porcelain 中的约定存储排除模式列表。
.gitignore
是每个目录的忽略文件。git status、git add、git rm 和git clean 会查看它,但核心 Git 命令不会查看它。另请参阅:gitignore[5]。 - info/attributes
-
定义要分配给路径的属性,类似于每个目录的
.gitattributes
文件。另请参阅:gitattributes[5]。 - info/sparse-checkout
-
此文件存储稀疏签出模式。另请参阅:git-read-tree[1]。
- remotes
-
存储 URL 和默认引用名的简写,以便在通过git fetch、git pull 和git push 命令与远程存储库交互时使用。有关详细信息,请参阅 git-fetch[1] 中的 REMOTES 部分。这种机制是传统的,不太可能在现代存储库中找到。如果设置了 $GIT_COMMON_DIR,则会忽略此目录,并将使用 "$GIT_COMMON_DIR/remotes" 代替。
- logs
-
对引用进行的更改记录存储在此目录中。有关更多信息,请参阅 git-update-ref[1]。如果设置了 $GIT_COMMON_DIR,则会忽略此目录(除了 logs/HEAD),并将使用 "$GIT_COMMON_DIR/logs" 代替。
- logs/refs/heads/
name
-
记录对名为
name
的分支尖端进行的所有更改。 - logs/refs/tags/
name
-
记录对名为
name
的标签进行的所有更改。 - shallow
-
这与
info/grafts
类似,但它由浅克隆机制在内部使用和维护。请参阅 git-clone[1] 和 git-fetch[1] 的--depth
选项。如果设置了 $GIT_COMMON_DIR,则会忽略此文件,并将使用 "$GIT_COMMON_DIR/shallow" 代替。 - commondir
-
如果此文件存在,如果未明确设置 $GIT_COMMON_DIR(请参阅 git[1]),则将其设置为此文件中指定的路径。如果指定的路径是相对路径,则它是相对于 $GIT_DIR 的。具有 commondir 的存储库是不完整的,除非有由 "commondir" 指向的存储库。
- modules
-
包含子模块的 git 存储库。
- worktrees
-
包含链接工作树的管理数据。每个子目录包含链接工作树的工作树相关部分。如果设置了 $GIT_COMMON_DIR,则会忽略此目录,在这种情况下,将使用 "$GIT_COMMON_DIR/worktrees" 代替。
- worktrees/<id>/gitdir
-
一个文本文件,包含指向此处的 .git 文件的绝对路径。这用于检查链接的存储库是否已被手动删除,并且不再需要保留此目录。每次访问链接的存储库时,都应更新此文件的 mtime。
- worktrees/<id>/locked
-
如果此文件存在,则链接的工作树可能位于可移植设备上,并且不可用。此文件的存在会阻止
worktrees/<id>
被git worktree prune
自动或手动修剪。该文件可能包含一个字符串,解释为什么存储库被锁定。 - worktrees/<id>/config.worktree
-
工作目录特定的配置文件。
Git 存储库格式版本
每个 git 存储库在其config
文件的core.repositoryformatversion
键中都标记有数字版本。此版本指定了对磁盘存储库数据进行操作的规则。不支持存储库中发布的特定版本的 git 实现,不得对该存储库进行操作;这样做不仅会导致结果错误,而且可能会丢失数据。
由于此规则,版本升级应保持最少。相反,我们通常更喜欢以下策略
-
升级单个数据文件的格式版本号(例如,索引、打包文件等)。这将不兼容性限制在这些文件。
-
引入新数据,这些数据在旧客户端使用时会优雅地降级(例如,旧客户端会忽略打包位图文件,这些文件只是没有利用它们提供的优化)。
整个存储库格式版本升级只应作为无法独立版本化的更改的一部分。例如,如果要更改对象的连通性规则或锁定引用的规则,则需要升级存储库格式版本。
请注意,这仅适用于直接访问存储库的磁盘内容。仅支持格式0
的旧客户端仍然可以通过git://
连接到使用格式1
的存储库,只要服务器进程支持格式1
。
推出版本升级(无论是整个存储库还是单个文件)的首选策略是教 git 读取新格式,并允许使用配置开关或命令行选项编写新格式(用于实验或不关心与旧 git 的向后兼容性的用户)。然后,在允许读取功能变得普遍的较长时间之后,我们可能会切换到默认情况下编写新格式。
当前定义的格式版本为
版本1
此格式与版本0
相同,以下例外情况除外
-
读取
core.repositoryformatversion
变量时,支持版本 1 的 git 实现还必须读取配置文件extensions
部分中找到的任何配置键。 -
如果版本 1 存储库指定了运行的 git 未实现的任何
extensions.*
键,则操作不得继续。同样,如果实现无法理解任何已知键的值,则操作不得继续。
请注意,如果配置文件中未指定任何扩展,则core.repositoryformatversion
应设置为0
(将其设置为1
没有任何好处,并且会使存储库与旧的 git 实现不兼容)。
本文档将作为扩展的总体列表。任何想要定义新扩展的实现都应在此处记录,以声明该名称。
定义的扩展为
preciousObjects
当配置键extensions.preciousObjects
设置为true
时,存储库中的对象不得被删除(例如,由git-prune
或git repack -d
删除)。
partialClone
当配置键extensions.partialClone
设置时,它表示存储库是使用部分克隆创建的(或后来执行了部分获取),并且远程可能省略了发送某些不需要的对象。此类远程被称为“承诺者远程”,它承诺将来可以从它获取所有这些省略的对象。
此键的值是承诺者远程的名称。
GIT
git[1] 套件的一部分