每个提交（除了项目中的第一个提交）都有一个父提交，该父提交显示了此提交之前发生的事情。沿着父提交链最终会将您带回项目的起点。

然而，提交并非构成一个简单的列表；Git 允许开发线分叉然后重新汇合，而两条开发线重新汇合的点称为“合并”。因此，代表合并的提交可以有多个父提交，每个父提交代表导致该点的开发线中的最新提交。

了解这一点最佳方式是使用 gitk[1] 命令；现在在 Git 仓库上运行 gitk 并查找合并提交将有助于理解 Git 如何组织历史。

在以下内容中，我们称提交 X 从提交 Y“可达”，如果提交 X 是提交 Y 的祖先。等价地，您可以说 Y 是 X 的后代，或者存在一条从提交 Y 到提交 X 的父提交链。

我们将有时使用如下所示的图表表示 Git 历史。提交显示为“o”，它们之间的链接用 - / 和 \ 绘制。时间从左到右。

如果我们需要讨论某个特定的提交，字符“o”可能会被另一个字母或数字替换。

当我们需要精确时，我们将使用“分支”一词来表示开发线，而“分支头指针”（或简称为“头指针”）来表示分支上最新提交的引用。在上例中，“A”这个分支头指针指向一个特定的提交，但我们称指向该点的三条提交线都属于“分支 A”。

然而，当不会引起混淆时，我们经常同时使用“分支”一词来表示分支和分支头指针。

假设您想知道自 mybranch 从 origin 分叉以来，您在该分支上进行了多少次提交。

或者，您可能经常看到类似的事情使用底层命令 git-rev-list[1] 来完成，它只列出所有给定提交的 SHA-1。

假设您想检查两个分支是否指向相同的历史点。

将告诉您两个分支上的项目内容是否相同；然而，理论上，相同的项目内容可能通过两种不同的历史路线到达。您可以比较对象名称。

或者，您可以回想一下 ... 操作符选择的是可达于任一引用但非两者都可达的提交；因此。

当两个分支相同时，将不返回任何提交。

假设您知道提交 e05db0fd 修复了某个问题。您想找到包含该修复的最早标记的发行版。

当然，可能不止一个答案—​如果历史在提交 e05db0fd 之后分叉，那么可能存在多个“最早”的标记发行版。

您可以仅通过目视检查自 e05db0fd 以来的提交。

或者您可以使用 git-name-rev[1]，它会根据指向提交后代的任何标签为提交命名。

git-describe[1] 命令执行相反的操作，使用基于给定提交的标签来命名修订。

但这有时可以帮助您猜测哪些标签可能出现在给定提交之后。

如果您只想验证给定的标记版本是否包含给定的提交，您可以使用 git-merge-base[1]。

merge-base 命令查找给定提交的共同祖先，并在一个提交是另一个的后代的情况下返回其中一个；因此，上面的输出表明 e05db0fd 实际上是 v1.5.0-rc1 的祖先。

或者，请注意。

当且仅当 v1.5.0-rc1 包含 e05db0fd 时，将产生空输出，因为它只输出不可从 v1.5.0-rc1 可达的提交。

作为另一种选择，git-show-branch[1] 命令列出从其参数可达的提交，并在左侧显示指示该提交可从哪些参数可达的指示器。因此，如果您运行类似。

那么一行像。

表示 e05db0fd 可从自身、v1.5.0-rc1 和 v1.5.0-rc2 可达，但不可从 v1.5.0-rc0 可达。

假设您想查看所有可从名为 master 的分支头指针可达，但不能从您仓库中的任何其他头指针可达的提交。

我们可以使用 git-show-ref[1] 列出此仓库中的所有头指针。

我们可以获取仅分支头指针名称，并使用 cut 和 grep 等标准实用程序删除 master。

然后，我们可以要求显示所有从 master 可达但从这些其他头指针不可达的提交。

显然，可能存在无数种变体；例如，要查看可从某个头指针可达但从仓库中的任何标签不可达的所有提交。

(参见 gitrevisions[7] 关于提交选择语法的说明，例如 --not。)

git-archive 命令可以从项目的任何版本创建 tar 或 zip 归档；例如

将使用 HEAD 来生成一个 gzipped tar 归档，其中每个文件名都以 project/ 作为前缀。如果可能，输出文件的格式会根据输出文件的扩展名来推断，有关详细信息请参阅 git-archive[1]。

版本低于 1.7.7 的 Git 不支持 tar.gz 格式，您需要显式地使用 gzip

如果您要发布一个软件项目的新版本，您可能希望同时创建一个变更日志以包含在发布公告中。

例如，Linus Torvalds 通过标记新内核版本，然后运行

其中 release-script 是一个 shell 脚本，看起来像

然后他只是复制粘贴输出命令，在确认它们看起来没问题后。

有人给了您一个文件的副本，并询问哪个提交修改了该文件，使得该文件在提交之前或之后包含给定的内容。您可以使用以下方法找出

这个命令的工作原理留给（高级）学生作为练习。git-log[1]、git-diff-tree[1] 和 git-hash-object[1] 的 man 页可能会有所帮助。

Git 能够自动合并的所有更改已添加到索引文件中，因此 git-diff[1] 只显示冲突。它使用一种不寻常的语法

回想一下，在解决此冲突后将要提交的提交将有两个父提交，而不是通常的一个：一个父提交将是 HEAD，即当前分支的尖端；另一个将是另一个分支的尖端，它临时存储在 MERGE_HEAD 中。

在合并期间，索引中包含每个文件的三个版本。这三个“文件阶段”中的每一个都代表了文件的不同版本

当您要求 git-diff[1] 显示冲突时，它会在工作树中的冲突合并结果与阶段 2 和 3 之间进行三方 diff，以仅显示来自双方的内容块，混合在一起（换句话说，当一个块的合并结果仅来自阶段 2 时，该部分不冲突而不显示。同一情况适用于阶段 3）。

上面的 diff 显示了 file.txt 的工作树版本与阶段 2 和阶段 3 版本之间的差异。因此，而不是在每行前面加上一个单一的 + 或 -，它现在使用两列：第一列用于第一个父提交和工作目录副本之间的差异，第二列用于第二个父提交和工作目录副本之间的差异。（有关格式的详细信息，请参阅 git-diff-files[1] 的“COMBINED DIFF FORMAT”部分。）

在以明显的方式解决冲突后（但在更新索引之前），diff 将如下所示

这表明我们的已解决版本从第一个父提交中删除了“Hello world”，从第二个父提交中删除了“Goodbye”，并添加了“Goodbye world”，而后者以前在两者中都不存在。

一些特殊的 diff 选项允许 diff 工作目录与这些阶段中的任何一个进行比较

当使用ort合并策略（默认）时，在用合并结果更新工作树之前，Git 会写入一个名为 AUTO_MERGE 的引用，该引用反映了它将要写入的树的状态。文本冲突无法自动合并的路径会像在工作树中一样，以冲突标记的形式写入此树。因此，AUTO_MERGE 可以与 git-diff[1] 一起使用，以显示您为解决冲突所做的更改。使用与上面相同的示例，在解决冲突后，我们得到

请注意，diff 显示我们删除了冲突标记和内容行的两个版本，而是写入了“Goodbye world”。

git-log[1] 和 gitk[1] 命令也为合并提供了特殊帮助

这将显示仅存在于 HEAD 或 MERGE_HEAD 中的所有提交，并且触及了未合并的文件。

您还可以使用 git-mergetool[1]，它允许您使用 Emacs 或 kdiff3 等外部工具合并未合并的文件。

每次您解决一个文件中的冲突并更新索引

该文件的不同阶段将被“折叠”，之后 git diff（默认情况下）将不再显示该文件的 diff。

创建一个新提交来撤销早期更改非常容易；只需将 git-revert[1] 命令指向有问题的提交；例如，要撤销最新的提交

这将创建一个新的提交，该提交撤销 HEAD 中的更改。您将有机会编辑新提交的提交消息。

您也可以撤销早期更改，例如，倒数第二个

在这种情况下，Git 将尝试撤销旧的更改，同时保持自那时以来的所有更改不变。如果最近的更改与要撤销的更改重叠，那么您将被要求手动修复冲突，就像在 解决合并 的情况下一样。

如果出现问题的提交是最近的提交，并且您尚未公开该提交，那么您可以通过 git reset --hard 来销毁它。

或者，您可以像要 创建新提交 一样，编辑工作目录并更新索引来修复您的错误，然后运行

这将用包含您更改的新提交替换旧提交，让您有机会先编辑旧的提交消息。

同样，您永远不应该对可能已经合并到另一个分支的提交执行此操作；在这种情况下，请使用 git-revert[1]。

也可以替换历史中更远的提交，但这属于高级主题，应留待 另一章。

在撤销先前错误的更改时，您可能会发现使用 git-restore[1] 检出文件的旧版本很有用。命令

将 path/to/file 替换为它在 HEAD^ 提交中的内容，并更新索引以匹配。它不会更改分支。

如果您只想查看文件的旧版本，而不想修改工作目录，您可以使用 git-show[1] 来完成

这将显示给定版本的文件。

当您正在处理复杂的事情时，发现了一个不相关的但明显且微小的错误。您希望在继续之前修复它。您可以使用 git-stash[1] 来保存当前的工作状态，然后在修复错误后（或选择性地在不同的分支上进行修复，然后再返回），撤销未完成的工作。

此命令会将您的更改保存到 stash，并将您的工作树和索引重置为与当前分支的尖端匹配。然后您可以像平常一样进行修复。

之后，您可以使用 git stash pop 恢复到您正在进行的工作

git-fsck[1] 命令对仓库运行一系列一致性检查，并报告任何问题。这可能需要一些时间。

您将看到关于悬空对象的通知消息。它们是仍然存在于仓库中但不再被任何分支引用的对象，并且可以在一段时间后被 gc 移除（并且将会被移除）。您可以运行 git fsck --no-dangling 来抑制这些消息，并仍然查看真正的错误。

假设您的个人仓库位于目录 ~/proj 中。我们首先创建一个仓库的新克隆，并告知 git daemon 它打算公开

生成的 proj.git 目录包含一个“裸” Git 仓库——​它只是 .git 目录的内容，而没有在其周围检出任何文件。

接下来，将 proj.git 复制到您打算托管公共仓库的服务器上。您可以使用 scp、rsync 或任何最方便的方式。

这是首选方法。

如果有人另外管理服务器，他们应该告诉您应将仓库放在哪个目录中，以及它将出现在哪个 git:// URL。然后您可以跳到下面的“将更改推送到公共仓库”部分。

否则，您所要做的就是启动 git daemon；它将监听端口 9418。默认情况下，它允许访问任何看起来像 Git 目录且包含特殊文件 git-daemon-export-ok 的目录。将一些目录路径作为 git daemon 参数传递将进一步限制导出的目录到那些路径。

您也可以将 git daemon 作为 inetd 服务运行；有关详细信息，请参阅 git-daemon[1] man 页。（尤其请参阅示例部分。）

Git 协议提供更好的性能和可靠性，但对于已设置了 Web 服务器的主机，HTTP 导出可能更易于设置。

您所要做的就是将新创建的裸 Git 仓库放在由 Web 服务器导出的目录中，并进行一些调整以提供 Web 客户端所需的一些额外信息

（有关最后两行的解释，请参阅 git-update-server-info[1] 和 githooks[5]。）

宣布 proj.git 的 URL。其他人应该能够从该 URL 克隆或拉取，例如使用如下命令行

（另请参阅 setup-git-server-over-http，了解使用 WebDAV 的稍微更复杂的设置，该设置也允许通过 HTTP 推送。）

请注意，上面概述的两种技术（通过 http 或 git 导出）允许其他维护者获取您的最新更改，但它们不允许写入访问，而您需要写入访问才能用您的私有仓库创建的最新更改来更新公共仓库。

最简单的方法是使用 git-push[1] 和 ssh；要使用您名为 master 的分支的最新状态更新名为 master 的远程分支，请运行

或者只是

与 git fetch 类似，git push 会在不导致 快进 时报错；请参阅下一节了解处理这种情况的详细信息。

请注意，push 的目标通常是 裸 仓库。您也可以推送到具有已签出工作树的仓库，但为了避免混淆，默认情况下会拒绝推送到更新当前已签出分支的操作。有关详细信息，请参阅 git-config[1] 中 receive.denyCurrentBranch 选项的描述。

与 git fetch 类似，您也可以设置配置选项来节省输入；所以，例如

将以下内容添加到 .git/config

这允许您使用以下命令执行相同的推送

有关详细信息，请参阅 remote..url、branch..remote 和 remote..push 选项在 git-config[1] 中的说明。

如果推送不会导致远程分支 快进，那么它将以类似以下的错误失败

例如，这可能发生，如果您

您可以通过在分支名称前加上加号来强制 git push 仍然执行更新。

注意加号 + 的添加。 或者，您可以使用 -f 标志来强制远程更新，如

通常，当公共仓库中的分支头发生修改时，它会修改为指向之前指向的提交的后继者。通过强制推送在这种情况下，您打破了这一惯例。（参见 重写历史的问题。）

尽管如此，这对于那些需要一种简单方式来发布正在进行中的补丁系列的人来说是一种常见的做法，只要您警告其他开发人员您打算如何管理该分支，它就是一种可接受的折衷方案。

当其他人有权推送到同一个仓库时，推送也可能以这种方式失败。在这种情况下，正确的解决方案是在先更新工作后重试推送：可以通过 pull，或通过 fetch 后跟 rebase 来完成；有关更多信息，请参见 下一节 和 gitcvs-migration[7]。

另一种协作方式是使用与 CVS 中常用的模型相似的模型，其中具有特殊权限的几位开发人员都推送到并从单个共享仓库中拉取。有关如何设置此项的说明，请参见 gitcvs-migration[7]。

但是，虽然 Git 对共享仓库的支持没有任何问题，但这种操作模式通常不推荐，仅仅因为 Git 支持的协作模式——通过交换补丁和从公共仓库拉取——与中央共享仓库相比有许多优势。

gitweb cgi 脚本为用户提供了一种简单的方式来浏览项目的修订、文件内容和日志，而无需安装 Git。像 RSS/Atom feed 和 blame/annotation 详细信息这样的功能可以被选择性地启用。

git-instaweb[1] 命令提供了一种使用 gitweb 浏览仓库的简单方法。使用 instaweb 时的默认服务器是 lighttpd。

有关与具有 CGI 或 Perl 功能的服务器进行永久安装的详细设置说明，请参见 Git 源代码树中的 gitweb/INSTALL 文件和 gitweb[1]。

这描述了 Tony Luck 在他作为 Linux 内核 IA64 架构维护者的角色中如何使用 Git。

他使用两个公共分支

他还使用一组临时分支（“主题分支”），每个分支包含逻辑分组的补丁。

要进行设置，首先通过克隆 Linus 的公共树来创建您的工作树。

Linus 的树将存储在名为 origin/master 的远程跟踪分支中，并可以使用 git-fetch[1] 进行更新；您可以使用 git-remote[1] 设置“远程”并使用 git-fetch[1] 来跟踪其他公共树并使其保持最新；请参见 仓库和分支。

现在创建您将要工作的分支；这些分支最初位于 origin/master 分支的当前尖端，并且应该（使用 git-branch[1] 的 --track 选项）设置以默认合并 Linus 的更改。

可以使用 git-pull[1] 轻松地使它们保持最新。

重要提示！如果您在这些分支中有任何本地更改，那么此合并将创建一个提交对象到历史记录中（如果没有本地更改，Git 将简单地执行“快进”合并）。许多人不喜欢这会在 Linux 历史中产生的“噪音”，因此您应该在 release 分支中避免随意执行此操作，因为当您要求 Linus 从 release 分支拉取时，这些带有噪音的提交将成为永久历史的一部分。

一些配置变量（参见 git-config[1]）可以轻松地将两个分支推送到您的公共树。（参见 设置公共仓库。）

然后您可以使用 git-push[1] 推送 test 和 release 树。

或者使用以下命令仅推送 test 和 release 分支中的一个。

或

现在应用来自社区的一些补丁。考虑一个简短的、有吸引力的名称来保存此补丁（或一组相关补丁）的分支，并从 Linus 分支的一个最近的稳定标签创建新分支。为您的分支选择一个稳定的基础将：1）帮助您：通过避免包含不相关且可能未经充分测试的更改；2）帮助未来的 bug 猎人使用 git bisect 来查找问题。

现在应用补丁，运行一些测试，并提交更改。如果补丁是多部分系列，则应将其作为单独的提交应用于此分支。

当您对更改的状态满意时，您可以将其合并到“test”分支中，以准备公开。

这里不太可能发生冲突……但如果您在此步骤上花费了大量时间并且还从上游拉取了新版本，则可能会发生冲突。

过一段时间后，当有足够的时间并且测试完成时，您可以将同一分支拉到 release 树中，准备好向上游提交。这就是您看到将每个补丁（或补丁系列）保留在其自己的分支中的价值的地方。这意味着补丁可以按任何顺序移动到 release 树中。

一段时间后，您将拥有许多分支，并且尽管您为每个分支选择了精心设计的名称，您可能会忘记它们的作用或它们的状态。要获得关于特定分支中包含哪些更改的提醒，请使用

要查看它是否已合并到 test 或 release 分支中，请使用

或

（如果此分支尚未合并，您将看到一些日志条目。如果已合并，则不会有输出。）

一旦补丁完成了整个周期（从 test 移动到 release，然后被 Linus 拉取，最后回到您的本地 origin/master 分支），此更改的分支就不再需要了。当以下命令的输出为空时，您会检测到这一点。

此时可以删除该分支。

有些更改非常微小，以至于不需要创建单独的分支然后合并到 test 和 release 分支中。对于这些更改，只需直接应用于 release 分支，然后将其合并到 test 分支中。

将您的工作推送到 mytree 后，您可以使用 git-request-pull[1] 来准备一个“请拉取”请求消息发送给 Linus。

这里有一些脚本可以使这一切更加简单。

“commit”对象将 tree 的物理状态与如何到达那里以及为什么的描述联系起来。使用 --pretty=raw 选项来 git-show[1] 或 git-log[1] 来检查您最喜欢的提交。

如您所见，提交由以下内容定义：

Note that a commit does not itself contain any information about what actually changed; all changes are calculated by comparing the contents of the tree referred to by this commit with the trees associated with its parents. In particular, Git does not attempt to record file renames explicitly, though it can identify cases where the existence of the same file data at changing paths suggests a rename. (See, for example, the -M option to git-diff[1]). 注意，提交本身不包含任何关于实际更改的信息；所有更改都是通过比较此提交引用的树的内容与其 parent 相关的树的内容来计算的。特别是，Git 不会显式记录文件重命名，尽管它可以识别出在不同路径下存在相同文件数据的情况，这表明存在重命名。（例如，请参阅 git-diff[1] 的 -M 选项）。

A commit is usually created by git-commit[1], which creates a commit whose parent is normally the current HEAD, and whose tree is taken from the content currently stored in the index. 提交通常由 git-commit[1] 创建，它创建一个 parent 通常是当前 HEAD 的提交，其 tree 取自当前存储在索引中的内容。

The ever-versatile git-show[1] command can also be used to examine tree objects, but git-ls-tree[1] will give you more details. 万能的 git-show[1] 命令也可以用来检查 tree 对象，但 git-ls-tree[1] 会提供更多细节。

As you can see, a tree object contains a list of entries, each with a mode, object type, SHA-1 name, and name, sorted by name. It represents the contents of a single directory tree. 从图中可以看到，一个 tree 对象包含一个条目列表，每个条目都具有模式、对象类型、SHA-1 名称和名称，并按名称排序。它代表单个目录树的内容。

The object type may be a blob, representing the contents of a file, or another tree, representing the contents of a subdirectory. Since trees and blobs, like all other objects, are named by the SHA-1 hash of their contents, two trees have the same SHA-1 name if and only if their contents (including, recursively, the contents of all subdirectories) are identical. This allows Git to quickly determine the differences between two related tree objects, since it can ignore any entries with identical object names. 对象类型可以是 blob，代表文件的内容，也可以是另一个 tree，代表子目录的内容。由于 tree 和 blob，与其他所有对象一样，都以其内容的 SHA-1 哈希命名，因此两个 tree 拥有相同的 SHA-1 名称当且仅当它们的内容（包括递归地，所有子目录的内容）相同。这使得 Git 能够快速确定两个相关 tree 对象之间的差异，因为它会忽略任何具有相同对象名称的条目。

(Note: in the presence of submodules, trees may also have commits as entries. See Submodules for documentation.) （注意：在存在子模块的情况下，tree 也可能包含 commit 作为条目。有关文档，请参阅 Submodules。）

Note that the files all have mode 644 or 755: Git actually only pays attention to the executable bit. 请注意，文件都具有 644 或 755 的权限：Git 实际上只关注可执行位。

You can use git-show[1] to examine the contents of a blob; take, for example, the blob in the entry for COPYING from the tree above. 您可以使用 git-show[1] 检查 blob 的内容；例如，从上面的 tree 中取 COPYING 条目中的 blob。

A "blob" object is nothing but a binary blob of data. It doesn’t refer to anything else or have attributes of any kind. 一个“blob”对象只不过是一块二进制数据。它不指向任何其他东西，也没有任何类型的属性。

Since the blob is entirely defined by its data, if two files in a directory tree (or in multiple different versions of the repository) have the same contents, they will share the same blob object. The object is totally independent of its location in the directory tree, and renaming a file does not change the object that file is associated with. 由于 blob 完全由其数据定义，因此如果目录树中的两个文件（或存储库的多个不同版本）具有相同的内容，它们将共享相同的 blob 对象。该对象完全独立于其在目录树中的位置，重命名文件不会改变该文件关联的对象。

Note that any tree or blob object can be examined using git-show[1] with the <revision>:<path> syntax. This can sometimes be useful for browsing the contents of a tree that is not currently checked out. 请注意，任何 tree 或 blob 对象都可以使用 git-show[1] 和 <revision>:<path> 语法进行检查。这有时对于浏览当前未签出的 tree 的内容很有用。

If you receive the SHA-1 name of a blob from one source, and its contents from another (possibly untrusted) source, you can still trust that those contents are correct as long as the SHA-1 name agrees. This is because the SHA-1 is designed so that it is infeasible to find different contents that produce the same hash. 如果您从一个来源接收到 blob 的 SHA-1 名称，并从另一个（可能不可信）来源接收到其内容，只要 SHA-1 名称匹配，您仍然可以信任这些内容是正确的。这是因为 SHA-1 的设计使得找到生成相同哈希的不同内容是不可能的。

Similarly, you need only trust the SHA-1 name of a top-level tree object to trust the contents of the entire directory that it refers to, and if you receive the SHA-1 name of a commit from a trusted source, then you can easily verify the entire history of commits reachable through parents of that commit, and all of those contents of the trees referred to by those commits. 同样，您只需要信任顶级 tree 对象的文件名即可信任它引用的整个目录的内容，如果您从受信任的来源接收到 commit 的 SHA-1 名称，那么您就可以轻松地验证通过该 commit 的 parent 可达的所有 commit 历史，以及那些 commit 引用的 tree 的所有内容。

So to introduce some real trust in the system, the only thing you need to do is to digitally sign just one special note, which includes the name of a top-level commit. Your digital signature shows others that you trust that commit, and the immutability of the history of commits tells others that they can trust the whole history. 因此，要在系统中引入真正的信任，您只需要做的是对一个特殊的说明进行数字签名，该说明包含顶级 commit 的名称。您的数字签名向他人表明您信任该 commit，而 commit 历史的不可变性则告诉他人他们可以信任整个历史。

In other words, you can easily validate a whole archive by just sending out a single email that tells the people the name (SHA-1 hash) of the top commit, and digitally sign that email using something like GPG/PGP. 换句话说，您可以通过发送一封电子邮件来轻松验证整个存档，该电子邮件告诉人们顶级 commit 的名称（SHA-1 哈希），并使用 GPG/PGP 等工具对该电子邮件进行数字签名。

To assist in this, Git also provides the tag object…​ 为了协助此目的，Git 还提供了 tag 对象…

A tag object contains an object, object type, tag name, the name of the person ("tagger") who created the tag, and a message, which may contain a signature, as can be seen using git-cat-file[1]. 一个 tag 对象包含一个对象、对象类型、tag 名称、创建 tag 的人（“tagger”）的姓名以及一条消息，该消息可能包含签名，如使用 git-cat-file[1] 所见。

See the git-tag[1] command to learn how to create and verify tag objects. (Note that git-tag[1] can also be used to create "lightweight tags", which are not tag objects at all, but just simple references whose names begin with refs/tags/). 请参阅 git-tag[1] 命令了解如何创建和验证 tag 对象。（注意：git-tag[1] 也可用于创建“轻量级 tag”，它们根本不是 tag 对象，而只是名称以 refs/tags/ 开头的简单引用）。

Newly created objects are initially created in a file named after the object’s SHA-1 hash (stored in .git/objects). 新创建的对象最初会以对象的 SHA-1 哈希命名（存储在 .git/objects 中）的文件形式创建。

Unfortunately this system becomes inefficient once a project has a lot of objects. Try this on an old project. 不幸的是，一旦项目包含大量对象，这种系统就会变得效率低下。在旧项目上尝试此操作。

The first number is the number of objects which are kept in individual files. The second is the amount of space taken up by those "loose" objects. 第一个数字是保留在单个文件中的对象数量。第二个数字是这些“松散”对象占用的空间量。

You can save space and make Git faster by moving these loose objects in to a "pack file", which stores a group of objects in an efficient compressed format; the details of how pack files are formatted can be found in gitformat-pack[5]. 您可以通过将这些松散对象移至“pack 文件”来节省空间并提高 Git 的速度，pack 文件以高效的压缩格式存储一组对象；pack 文件的格式详情可以在 gitformat-pack[5] 中找到。

To put the loose objects into a pack, just run git repack. 要将松散对象放入 pack，只需运行 git repack。

This creates a single "pack file" in .git/objects/pack/ containing all currently unpacked objects. You can then run. 这会在 .git/objects/pack/ 中创建一个名为“pack 文件”的文件，其中包含所有当前未打包的对象。然后您可以运行。

to remove any of the "loose" objects that are now contained in the pack. This will also remove any unreferenced objects (which may be created when, for example, you use git reset to remove a commit). You can verify that the loose objects are gone by looking at the .git/objects directory or by running. 以删除现在包含在 pack 中的任何“松散”对象。这还将删除任何未引用的对象（例如，当您使用 git reset 删除提交时可能会创建这些对象）。您可以通过查看 .git/objects 目录或运行来验证松散对象是否已消失。

Although the object files are gone, any commands that refer to those objects will work exactly as they did before. 尽管对象文件已消失，但任何引用这些对象的命令都会像以前一样工作。

The git-gc[1] command performs packing, pruning, and more for you, so is normally the only high-level command you need. git-gc[1] 命令为您执行打包、修剪等操作，因此通常是您唯一需要的高级命令。

The git-fsck[1] command will sometimes complain about dangling objects. They are not a problem. git-fsck[1] 命令有时会抱怨悬空对象。它们不是问题。

The most common cause of dangling objects is that you’ve rebased a branch, or you have pulled from somebody else who rebased a branch—​see Rewriting history and maintaining patch series. In that case, the old head of the original branch still exists, as does everything it pointed to. The branch pointer itself just doesn’t, since you replaced it with another one. 悬空对象最常见的原因是您 rebase 了某个分支，或者您从 rebase 了某个分支的其他人那里 pull 了——请参阅 Rewriting history and maintaining patch series。在这种情况下，原始分支的旧 head 仍然存在，它指向的所有内容也一样。分支指针本身不存在了，因为您用另一个替换了它。

There are also other situations that cause dangling objects. For example, a "dangling blob" may arise because you did a git add of a file, but then, before you actually committed it and made it part of the bigger picture, you changed something else in that file and committed that updated thing—​the old state that you added originally ends up not being pointed to by any commit or tree, so it’s now a dangling blob object. 还有其他导致悬空对象的情况。例如，一个“悬空 blob”可能由于您添加了一个文件，然后在您实际提交它并将其纳入整体之前，您更改了该文件中的其他内容并提交了更新的内容——您最初添加的旧状态最终没有被任何提交或 tree 指向，因此现在它是一个悬空 blob 对象。

Similarly, when the "ort" merge strategy runs, and finds that there are criss-cross merges and thus more than one merge base (which is fairly unusual, but it does happen), it will generate one temporary midway tree (or possibly even more, if you had lots of criss-crossing merges and more than two merge bases) as a temporary internal merge base, and again, those are real objects, but the end result will not end up pointing to them, so they end up "dangling" in your repository. 同样，当“ort”合并策略运行时，发现存在交叉合并，从而有多个合并基（这相当罕见，但确实会发生），它将生成一个临时中间 tree（如果有很多交叉合并和两个以上的合并基，甚至可能更多）作为临时的内部合并基，同样，这些都是真实的对象，但最终结果不会指向它们，因此它们最终会“悬空”在您的存储库中。

Generally, dangling objects aren’t anything to worry about. They can even be very useful: if you screw something up, the dangling objects can be how you recover your old tree (say, you did a rebase, and realized that you really didn’t want to—​you can look at what dangling objects you have, and decide to reset your head to some old dangling state). 通常，悬空对象没什么可担心的。它们甚至可能非常有用：如果您搞砸了什么，悬空对象可以帮助您恢复旧的 tree（例如，您 rebase 了，并意识到您真的不想这样做——您可以查看您拥有的悬空对象，并决定将您的 HEAD 重置到某个旧的悬空状态）。

For commits, you can just use. 对于 commit，您只需使用。

This asks for all the history reachable from the given commit but not from any branch, tag, or other reference. If you decide it’s something you want, you can always create a new reference to it, e.g. 这会查找从给定 commit 可达但不可从任何分支、tag 或其他引用可达的所有历史。如果您决定想要它，您可以随时创建一个新的引用指向它，例如。

For blobs and trees, you can’t do the same, but you can still examine them. You can just do. 对于 blob 和 tree，您不能做同样的事情，但仍然可以检查它们。您可以直接执行。

to show what the contents of the blob were (or, for a tree, basically what the ls for that directory was), and that may give you some idea of what the operation was that left that dangling object. 以显示 blob 的内容（或者，对于 tree，基本上是该目录的 ls 输出），这可能会让您对导致该悬空对象的那个操作有所了解。

Usually, dangling blobs and trees aren’t very interesting. They’re almost always the result of either being a half-way mergebase (the blob will often even have the conflict markers from a merge in it, if you have had conflicting merges that you fixed up by hand), or simply because you interrupted a git fetch with ^C or something like that, leaving some of the new objects in the object database, but just dangling and useless. 通常，悬空 blob 和 tree 并不太有趣。它们几乎总是以下情况的结果：要么是半途的合并基（如果发生过冲突合并且您手动修复过，blob 甚至可能包含合并的冲突标记），要么仅仅是因为您用 ^C 或类似的方式中断了 git fetch，导致一些新对象留在对象数据库中，但它们是悬空的且无用的。

Anyway, once you are sure that you’re not interested in any dangling state, you can just prune all unreachable objects. 无论如何，一旦您确定您对任何悬空状态不感兴趣，您就可以修剪所有不可达的对象。

and they’ll be gone. (You should only run git prune on a quiescent repository—​it’s kind of like doing a filesystem fsck recovery: you don’t want to do that while the filesystem is mounted. git prune is designed not to cause any harm in such cases of concurrent accesses to a repository but you might receive confusing or scary messages.) 它们就会消失。（您应该只在安静的存储库上运行 git prune ——这有点像进行文件系统 fsck 恢复：您不想在文件系统挂载时进行此操作。git prune 的设计目的是在这种并发访问存储库的情况下不会造成任何损害，但您可能会收到令人困惑或可怕的消息。）

By design, Git treats data trusted to it with caution. However, even in the absence of bugs in Git itself, it is still possible that hardware or operating system errors could corrupt data. Git 的设计宗旨是谨慎对待其信任的数据。然而，即使 Git 本身没有 bug，硬件或操作系统错误仍然可能损坏数据。

The first defense against such problems is backups. You can back up a Git directory using clone, or just using cp, tar, or any other backup mechanism. 防范此类问题的第一道防线是备份。您可以使用 clone 来备份 Git 目录，或者直接使用 cp、tar 或任何其他备份机制。

As a last resort, you can search for the corrupted objects and attempt to replace them by hand. Back up your repository before attempting this in case you corrupt things even more in the process. 作为最后的手段，您可以搜索损坏的对象并尝试手动替换它们。在尝试此操作之前，请备份您的存储库，以防您在此过程中使情况更加恶化。

We’ll assume that the problem is a single missing or corrupted blob, which is sometimes a solvable problem. (Recovering missing trees and especially commits is much harder). 我们假设问题是单个丢失或损坏的 blob，有时这是一个可解决的问题。（恢复丢失的 tree，尤其是 commit，会困难得多）。

Before starting, verify that there is corruption, and figure out where it is with git-fsck[1]; this may be time-consuming. 开始之前，请验证是否存在损坏，并使用 git-fsck[1] 找出其位置；这可能很耗时。

Assume the output looks like this. 假设输出如下所示。

Now you know that blob 4b9458b is missing, and that the tree 2d9263c6 points to it. If you could find just one copy of that missing blob object, possibly in some other repository, you could move it into .git/objects/4b/9458b3... and be done. Suppose you can’t. You can still examine the tree that pointed to it with git-ls-tree[1], which might output something like. 现在您知道 blob 4b9458b 丢失了，并且 tree 2d9263c6 指向它。如果您能找到那个丢失的 blob 对象的一个副本，可能在某个其他存储库中，您可以将其移动到 .git/objects/4b/9458b3... 并完成。假设您不能。您仍然可以使用 git-ls-tree[1] 检查指向它的 tree，这可能会输出类似以下内容：

So now you know that the missing blob was the data for a file named myfile. And chances are you can also identify the directory—​let’s say it’s in somedirectory. If you’re lucky the missing copy might be the same as the copy you have checked out in your working tree at somedirectory/myfile; you can test whether that’s right with git-hash-object[1]. 因此，现在您知道丢失的 blob 是名为 myfile 的文件的内容。并且很有可能您也可以识别出目录——假设它在 somedirectory 中。如果您幸运的话，丢失的副本可能与您在 somedirectory/myfile 的工作目录中签出的副本相同；您可以使用 git-hash-object[1] 来测试是否正确。

which will create and store a blob object with the contents of somedirectory/myfile, and output the SHA-1 of that object. if you’re extremely lucky it might be 4b9458b3786228369c63936db65827de3cc06200, in which case you’ve guessed right, and the corruption is fixed! 这将创建并存储一个具有 somedirectory/myfile 内容的 blob 对象，并输出该对象的 SHA-1。如果您非常幸运，它可能是 4b9458b3786228369c63936db65827de3cc06200，在这种情况下，您就猜对了，损坏就修复了！

Otherwise, you need more information. How do you tell which version of the file has been lost? 否则，您需要更多信息。您如何确定丢失了哪个文件版本？

The easiest way to do this is with. 最简单的方法是使用。

Because you’re asking for raw output, you’ll now get something like. 因为您要求原始输出，您现在会得到类似以下的内容。

This tells you that the immediately following version of the file was "newsha", and that the immediately preceding version was "oldsha". You also know the commit messages that went with the change from oldsha to 4b9458b and with the change from 4b9458b to newsha. 这告诉您，紧随其后的文件版本是“newsha”，而紧随其前的版本是“oldsha”。您还知道与从 oldsha 到 4b9458b 的更改以及从 4b9458b 到 newsha 的更改相关的 commit 消息。

If you’ve been committing small enough changes, you may now have a good shot at reconstructing the contents of the in-between state 4b9458b. 如果您提交的更改足够小，您现在可能很有希望重建 4b9458b 之间的状态内容。

If you can do that, you can now recreate the missing object with. 如果您能做到这一点，您现在就可以用…创建丢失的对象。

and your repository is good again! 您的存储库又好了！

(Btw, you could have ignored the fsck, and started with doing a. （顺便说一句，您可以忽略 fsck，然后开始执行）。

and just looked for the sha of the missing object (4b9458b) in that whole thing. It’s up to you—​Git does have a lot of information, it is just missing one particular blob version. 并在其中查找丢失对象的 sha（4b9458b）。这取决于您——Git确实有大量信息，只是缺少一个特定的 blob 版本。

The git-update-index[1] command updates the index with information from the working directory. You generally update the index information by just specifying the filename you want to update, like so. git-update-index[1] 命令使用工作目录中的信息更新索引。您通常只需指定要更新的文件名即可更新索引信息，例如。

but to avoid common mistakes with filename globbing etc., the command will not normally add totally new entries or remove old entries, i.e. it will normally just update existing cache entries. 但为了避免文件名通配等常见错误，该命令通常不会添加全新的条目或删除旧的条目，也就是说，它通常只会更新现有的缓存条目。

To tell Git that yes, you really do realize that certain files no longer exist, or that new files should be added, you should use the --remove and --add flags respectively. 要告诉 Git 是的，您确实意识到某些文件已不存在，或者应该添加新文件，您应该分别使用 --remove 和 --add 标志。

NOTE! A --remove flag does not mean that subsequent filenames will necessarily be removed: if the files still exist in your directory structure, the index will be updated with their new status, not removed. The only thing --remove means is that update-index will be considering a removed file to be a valid thing, and if the file really does not exist any more, it will update the index accordingly. 注意！--remove 标志不意味着后续文件名一定会被删除：如果文件仍然存在于您的目录结构中，索引将更新为它们的新状态，而不是被删除。 --remove 仅表示 update-index 将考虑删除的文件是有效的内容，如果文件确实不再存在，它将相应地更新索引。

As a special case, you can also do git update-index --refresh, which will refresh the "stat" information of each index to match the current stat information. It will not update the object status itself, and it will only update the fields that are used to quickly test whether an object still matches its old backing store object. 作为一种特殊情况，您还可以执行 git update-index --refresh，它将刷新每个索引的“stat”信息以匹配当前的 stat 信息。它不会更新对象本身的状态，并且它只会更新用于快速测试对象是否仍与其旧的后台存储对象匹配的字段。

The previously introduced git-add[1] is just a wrapper for git-update-index[1]. 之前介绍的 git-add[1] 只是 git-update-index[1] 的一个包装器。

You write your current index file to a "tree" object with the program. 您使用程序将当前的索引文件写入一个“tree”对象。

that doesn’t come with any options—​it will just write out the current index into the set of tree objects that describe that state, and it will return the name of the resulting top-level tree. You can use that tree to re-generate the index at any time by going in the other direction. 它没有任何选项——它只会将当前索引写入描述该状态的 tree 对象集合，并返回结果的顶级 tree 的名称。您可以在任何时候通过反向操作来使用该 tree 来重新生成索引。

You read a "tree" file from the object database, and use that to populate (and overwrite—​don’t do this if your index contains any unsaved state that you might want to restore later!) your current index. Normal operation is just. 您从对象数据库读取一个“tree”文件，并使用它来填充（并覆盖——如果您的索引包含任何您以后可能想恢复的未保存状态，请不要这样做！）您的当前索引。正常操作只是。

and your index file will now be equivalent to the tree that you saved earlier. However, that is only your index file: your working directory contents have not been modified. 并且您的索引文件现在将等同于您之前保存的 tree。但是，那只是您的索引文件：您的工作目录内容尚未被修改。

You update your working directory from the index by "checking out" files. This is not a very common operation, since normally you’d just keep your files updated, and rather than write to your working directory, you’d tell the index files about the changes in your working directory (i.e. git update-index). 您通过“签出”文件来从索引更新您的工作目录。这不是一个非常常见的操作，因为通常您会保持文件更新，而不是写入您的工作目录，您会告诉索引文件您工作目录中的更改（即 git update-index）。

However, if you decide to jump to a new version, or check out somebody else’s version, or just restore a previous tree, you’d populate your index file with read-tree, and then you need to check out the result with. 但是，如果您决定跳转到新版本，或签出别人的版本，或仅恢复以前的 tree，您将使用 read-tree 填充您的索引文件，然后您需要使用…签出结果。

or, if you want to check out all of the index, use -a. 或者，如果您想签出索引中的所有内容，请使用 -a。

NOTE! git checkout-index normally refuses to overwrite old files, so if you have an old version of the tree already checked out, you will need to use the -f flag (before the -a flag or the filename) to force the checkout. 注意！git checkout-index 通常拒绝覆盖旧文件，因此如果您已经签出了旧版本的 tree，您将需要使用 -f 标志（在 -a 标志或文件名之前）来强制签出。

Finally, there are a few odds and ends which are not purely moving from one representation to the other. 最后，还有一些零散的东西，它们不是纯粹地从一种表示形式移动到另一种形式。

要提交您通过 git write-tree 实例化出来的树，您需要创建一个“提交”对象，该对象引用该树以及其背后的历史记录——最重要的是，它引用了在历史记录中排在其前面的“父”提交。

通常，“提交”只有一个父提交：在某个更改发生之前的树的先前状态。但是，有时它可能有两个或更多父提交，在这种情况下，我们称之为“合并”，因为这种提交会将由其他提交表示的两个或多个先前状态“合并”在一起。

换句话说，虽然“树”表示工作目录的特定目录状态，“提交”表示该状态在时间轴上的位置，并解释了我们是如何到达那里的。

您通过提供描述提交时状态的树以及父提交列表来创建一个提交对象

然后通过标准输入（通过管道重定向或文件，或者直接在终端输入）提供提交原因。

git commit-tree 将返回表示该提交的对象名称，您应该将其保存以备后用。通常，您会提交一个新的 HEAD 状态，虽然 Git 不关心您将该状态的说明保存在哪里，但在实践中，我们倾向于将结果写入 .git/HEAD 指向的文件，以便我们始终可以看到最后一次提交的状态。

这是一张图，说明了各个部分如何组合在一起