设置和配置
获取和创建项目
基本快照
分支和合并
共享和更新项目
检查和比较
补丁
调试
外部系统
服务器管理
指南
管理
底层命令
-
2.49.0
2025-03-14
- 2.48.1 无更改
-
2.48.0
2025-01-10
- 2.45.1 → 2.47.2 无更改
-
2.45.0
2024-04-29
- 2.44.1 → 2.44.3 无更改
-
2.44.0
2024-02-23
- 2.43.2 → 2.43.6 无更改
-
2.43.1
2024-02-09
-
2.43.0
2023-11-20
- 2.39.1 → 2.42.4 无更改
-
2.39.0
2022-12-12
- 2.25.1 → 2.38.5 无更改
-
2.25.0
2020-01-13
- 2.24.1 → 2.24.4 无更改
-
2.24.0
2019-11-04
- 2.22.1 → 2.23.4 无更改
-
2.22.0
2019-06-07
- 2.20.1 → 2.21.4 无更改
-
2.20.0
2018-12-09
- 2.18.1 → 2.19.6 无更改
- 2.18.0 无更改
- 2.17.0 → 2.17.6 无更改
-
2.16.6
2019-12-06
-
2.15.4
2019-12-06
- 2.13.7 → 2.14.6 无更改
-
2.12.5
2017-09-22
- 2.11.4 无更改
-
2.10.5
2017-09-22
- 2.7.6 → 2.9.5 无更改
-
2.6.7
2017-05-05
-
2.5.6
2017-05-05
- 2.2.3 → 2.4.12 无更改
-
2.1.4
2014-12-17
-
2.0.5
2014-12-17
DESCRIPTION
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 获取器也尝试在远程使用它；如果您在 alternates 文件中使用相对路径（相对于对象数据库，而不是仓库！），这通常会起作用，但是如果您使用绝对路径，除非文件系统和 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/ 和 friends 记录的相同信息。请参阅 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"。Git 将在 Git 3.0 中停止从此目录读取 remotes。
- 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
-
该文件帮助“愚笨传输”方式发现此仓库中可用的引用（refs）。如果仓库以“愚笨传输”方式发布，则每次创建或修改标签或分支时，都应该通过 git update-server-info 重新生成此文件。通常，这是通过
hooks/update钩子完成的，当您使用 git push 推送到仓库时，git-receive-pack 命令会运行此钩子。 - info/grafts
-
该文件记录了虚假的提交祖先信息，用于模拟提交的父提交集与实际创建提交的方式不同。每行记录描述一个提交及其虚假父提交，通过列出它们以空格分隔并以换行符结尾的40字节十六进制对象名称。
请注意，嫁接（grafts）机制已经过时，可能导致在仓库之间传输对象时出现问题；请参阅 git-replace[1]，以获得更灵活、更健壮的系统来执行相同操作。
- info/exclude
-
按照约定，此文件存储排除模式列表。
.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" 代替。
Git 将在 Git 3.0 中停止从此目录读取 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 实现绝不能对该仓库进行操作；这样做不仅会产生错误的结果，而且实际上会丢失数据。
由于此规则，版本升级应保持在绝对最小值。相反，我们通常更喜欢以下策略：
-
提升各个数据文件（例如，索引、打包文件等）的格式版本号。这仅将不兼容性限制在这些文件上。
-
引入新的数据，当旧客户端使用时，该数据会优雅地降级（例如，旧客户端会忽略打包位图文件，它们只是不利用它们提供的优化）。
整个仓库格式的版本升级应仅是无法独立版本控制的更改的一部分。例如，如果有人要更改对象的可达性规则或锁定引用的规则，则需要升级仓库格式版本。
请注意，这仅适用于直接访问仓库的磁盘内容。只要服务器进程理解格式 1，即使是仅理解格式 0 的旧客户端仍然可以通过 git:// 连接到使用格式 1 的仓库。
推出版本升级（无论是整个仓库还是单个文件）的首选策略是教会 git 读取新格式，并允许使用配置开关或命令行选项来编写新格式（用于实验或对于那些不关心与旧 git 兼容性的人）。然后在允许读取功能变得普遍之后经过很长一段时间，我们可以切换到默认编写新格式。
当前定义的格式版本是：
版本 1
此格式与版本 0 相同，但以下例外：
-
读取
core.repositoryformatversion变量时，支持版本 1 的 git 实现还必须读取在配置文件的extensions部分中找到的任何配置键。 -
如果版本 1 仓库指定了运行中的 git 尚未实现的任何
extensions.*键，则操作绝不能继续。同样，如果实现不理解任何已知键的值，则操作绝不能继续。
请注意，如果在配置文件中未指定任何扩展，则 core.repositoryformatversion 应该设置为 0（将其设置为 1 没有任何好处，并且会使仓库与旧版本的 git 不兼容）。
已定义的扩展在 git-config[1] 的 extensions.* 部分中给出。任何希望定义新扩展的实现都应在此处注明，以便声明该名称。
GIT
属于 git[1] 套件的一部分
