在阅读本手册时，拥有一个 Git 仓库进行实验将非常有用。

获取仓库的最佳方式是使用 git-clone[1] 命令下载现有仓库的副本。如果您还没有想到项目，这里有一些有趣的例子

对于大型项目，初始克隆可能很耗时，但您只需克隆一次。

克隆命令会创建一个以项目命名的目录（在上面的示例中为 git 或 linux）。cd 进入此目录后，您会发现它包含项目文件的副本，称为工作树，以及一个名为 .git 的特殊顶级目录，其中包含项目的所有历史信息。

Git 最适合被视为存储文件集合历史记录的工具。它将历史记录存储为项目内容的相互关联的压缩快照集合。在 Git 中，每个这样的版本都称为提交。

这些快照不一定都从旧到新排列成一行；相反，工作可能会同时沿着平行的开发线进行，这些开发线称为分支，它们可以合并和分化。

一个 Git 仓库可以跟踪多个分支上的开发。它通过维护一个头列表来实现这一点，这些头引用了每个分支上的最新提交；git-branch[1] 命令显示分支头的列表

新克隆的仓库默认包含一个名为“master”的单个分支头，工作目录初始化为该分支头所引用的项目状态。

大多数项目也使用标签。标签和头一样，是对项目历史的引用，可以使用 git-tag[1] 命令列出

标签预期始终指向项目的相同版本，而头则预期随着开发进展而前进。

创建一个指向其中一个版本的新分支头，并使用 git-switch[1] 检出它

然后工作目录会反映项目在被标记为 v2.6.13 时的内容，并且 git-branch[1] 显示两个分支，星号标记当前已检出的分支

如果您决定想查看版本 2.6.17，您可以修改当前分支以指向 v2.6.17，使用

请注意，如果当前分支头是您对历史上特定点的唯一引用，那么重置该分支可能会导致您无法找到它曾经指向的历史记录；因此请谨慎使用此命令。

项目历史中的每个更改都由一个提交表示。git-show[1] 命令显示当前分支上的最新提交

如您所见，一次提交显示了谁进行了最新更改、他们做了什么以及原因。

每个提交都有一个 40 位的十六进制 ID，有时称为“对象名称”或“SHA-1 ID”，显示在 git show 输出的第一行。您通常可以使用更短的名称（例如标签或分支名称）来引用提交，但这个更长的名称也很有用。最重要的是，它是此提交的全局唯一名称：因此如果您告诉其他人对象名称（例如在电子邮件中），则可以保证该名称将引用其仓库中与您仓库中相同的提交（假设他们的仓库根本有该提交）。由于对象名称是根据提交内容计算的哈希值，因此可以保证提交永远不会在名称不变的情况下发生更改。

事实上，在 Git 概念 中我们将看到，Git 历史中存储的所有内容，包括文件数据和目录内容，都存储在一个对象中，该对象的名称是其内容的哈希值。

创建、删除和修改分支既快速又简单；以下是命令摘要

特殊符号“HEAD”始终可用于引用当前分支。事实上，Git 在 .git 目录中使用一个名为 HEAD 的文件来记住哪个分支是当前分支

git switch 命令通常需要一个分支头，但当使用 --detach 调用时，它也会接受任意提交；例如，您可以检出由标签引用的提交

HEAD 随后引用提交的 SHA-1 而不是分支，并且 git branch 显示您不再位于任何分支上

在这种情况下，我们说 HEAD 是“分离的”。

这是检出特定版本的简单方法，而无需为新分支命名。如果您决定这样做，稍后仍然可以为这个版本创建一个新分支（或标签）。

您克隆时创建的“master”分支是您克隆来源仓库中 HEAD 的副本。不过，该仓库可能还有其他分支，并且您的本地仓库会保留跟踪这些远程分支的本地跟踪分支，您可以使用 git-branch[1] 的 -r 选项查看它们

在此示例中，“origin”被称为远程仓库，或简称“remote”。从我们的角度来看，此仓库的分支被称为“远程分支”。上面列出的远程跟踪分支是在克隆时根据远程分支创建的，并将通过 git fetch（因此是 git pull）和 git push 进行更新。有关详细信息，请参阅 使用 git fetch 更新仓库。

您可能希望在自己的分支上基于这些远程跟踪分支之一进行构建，就像您对标签所做的那样

您也可以直接检出 origin/todo 以查看或编写一次性补丁。请参阅 分离头。

请注意，“origin”名称只是 Git 默认用来指代您克隆来源仓库的名称。

分支、远程跟踪分支和标签都是对提交的引用。所有引用都以 refs 开头的斜杠分隔路径名命名；我们目前使用的名称实际上是简写

如果例如存在同名的标签和分支，则完整名称偶尔会很有用。

（新创建的引用实际上存储在 .git/refs 目录下，位于其名称给定的路径下。然而，出于效率原因，它们也可以打包在一个文件中；请参阅 git-pack-refs[1]）。

另一个有用的快捷方式是，仓库的“HEAD”可以直接使用该仓库的名称来引用。因此，例如，“origin”通常是仓库“origin”中 HEAD 分支的快捷方式。

有关 Git 检查引用的完整路径列表，以及当存在多个具有相同简写名称的引用时它用于决定选择哪个的顺序，请参阅 gitrevisions[7] 手册页的“指定修订”部分。

克隆仓库并提交您自己的更改后，您可能希望检查原始仓库是否有更新。

不带任何参数的 git-fetch 命令会将所有远程跟踪分支更新为原始仓库中找到的最新版本。它不会触及您自己的任何分支——甚至包括为您在克隆时创建的“master”分支。

您还可以使用 git-remote[1] 跟踪您克隆来源仓库以外的其他仓库中的分支

新的远程跟踪分支将存储在您提供给 git remote add 的简写名称下，在本例中为 staging

如果您稍后运行 git fetch <remote>，则指定 <remote> 的远程跟踪分支将被更新。

如果您查看文件 .git/config，您会发现 Git 添加了一个新的节

这就是 Git 跟踪远程分支的原因；您可以通过使用文本编辑器编辑 .git/config 来修改或删除这些配置选项。（有关详细信息，请参阅 git-config[1] 的“配置文件”部分。）

假设您的项目版本 2.6.18 正常工作，但“master”上的版本崩溃了。有时，找到这种回归原因的最佳方法是在项目历史中执行暴力搜索，以找到导致问题的特定提交。git-bisect[1] 命令可以帮助您完成此操作

此时如果您运行 git branch，您会看到 Git 暂时将您移动到了“（无分支）”状态。HEAD 现在已从任何分支分离，并直接指向一个提交（提交 ID 为 65934），该提交可从“master”到达但无法从 v2.6.18 到达。编译并测试它，看看是否会崩溃。假设它确实崩溃了。然后

检出旧版本。像这样继续，在每个阶段告诉 Git 它给您的版本是好的还是坏的，并注意每次剩余要测试的修订版数量大约减少一半。

大约 13 次测试（在本例中）后，它将输出导致问题的提交的提交 ID。然后您可以使用 git-show[1] 检查该提交，找出是谁编写的，并附上提交 ID 给他们发送错误报告。最后，运行

将您返回到之前的分支。

请注意，git bisect 在每个点为您检出的版本只是一个建议，如果您认为这是一个好主意，您可以自由尝试不同的版本。例如，有时您可能会遇到一个破坏了不相关内容的提交；运行

它将运行 gitk 并用一个标记“bisect”来标记它选择的提交。选择一个看起来安全的附近提交，记下其提交 ID，然后使用以下命令检出它

然后测试，根据需要运行 bisect good 或 bisect bad，然后继续。

除了 git bisect visualize 然后 git reset --hard fb47ddb2db 之外，您可能只想告诉 Git 您想跳过当前提交

然而，在这种情况下，Git 最终可能无法区分一些最初跳过的提交和后续的坏提交中第一个坏的那个。

如果您有一个可以区分好提交和坏提交的测试脚本，也有方法可以自动化二分查找过程。有关此功能和其他 git bisect 功能的更多信息，请参阅 git-bisect[1]。

我们已经看到几种命名提交的方式

还有更多方式；有关命名修订的完整列表，请参阅 gitrevisions[7] 手册页的“指定修订”部分。一些示例

回想一下，合并提交可能有一个以上的父提交；默认情况下，^ 和 ~ 跟随提交中列出的第一个父提交，但您也可以选择

除了 HEAD 之外，还有其他几个特殊的提交名称

合并（稍后讨论）以及诸如 git reset 之类的操作（它们会更改当前检出的提交），通常会将 ORIG_HEAD 设置为当前操作之前 HEAD 的值。

git fetch 操作始终将最后获取的分支的头存储在 FETCH_HEAD 中。例如，如果您运行 git fetch 而不指定本地分支作为操作目标

获取的提交仍将可通过 FETCH_HEAD 获取。

当我们讨论合并时，我们还会看到特殊名称 MERGE_HEAD，它指的是我们要合并到当前分支中的另一个分支。

git-rev-parse[1] 命令是一个低级命令，偶尔可用于将提交的某个名称转换为该提交的对象名称

我们还可以创建一个标签来引用某个特定提交；运行以下命令后

您可以使用 stable-1 来引用提交 1b2e1d63ff。

这会创建一个“轻量级”标签。如果您还想在标签中包含评论，并可能对其进行加密签名，那么您应该改为创建一个标签对象；有关详细信息，请参阅 git-tag[1] 手册页。

git-log[1] 命令可以显示提交列表。它本身显示所有可从父提交到达的提交；但您也可以提出更具体的请求

当然，您可以将所有这些结合起来；以下命令查找自 v2.5 以来修改过 Makefile 或 fs 下任何文件的提交

您还可以要求 git log 显示补丁

有关更多显示选项，请参阅 git-log[1] 手册页中的 --pretty 选项。

请注意，git log 从最新提交开始，然后向后遍历其父提交；然而，由于 Git 历史可以包含多个独立的开发线，因此提交的特定列出顺序可能有些随意。

您可以使用 git-diff[1] 在任意两个版本之间生成差异

这会生成两个分支尖端之间的差异。如果您希望找到从它们的共同祖先到测试的差异，您可以使用三个点而不是两个点

有时您需要的是一组补丁；为此您可以使用 git-format-patch[1]

将生成一个文件，其中包含可从 test 访问但不能从 master 访问的每个提交的补丁。

您总是可以通过先检出正确的修订版本来查看文件的旧版本。但有时更方便的是无需检出任何内容即可查看单个文件的旧版本；此命令可实现这一点

冒号前可以是任何命名提交的内容，冒号后可以是 Git 跟踪的文件的任何路径。

在创建任何提交之前，你应该向 Git 介绍你自己。最简单的方法是使用 git-config[1]

这将在你的主目录中名为 .gitconfig 的文件中添加以下内容

有关配置文件的详细信息，请参阅 git-config[1] 的“配置文件”部分。该文件是纯文本文件，因此你也可以使用你喜欢的编辑器对其进行编辑。

从头开始创建一个新仓库非常简单

如果你有一些初始内容（例如，一个 tarball）

创建一个新提交需要三个步骤

在实践中，你可以根据需要多次交替和重复步骤 1 和 2：为了跟踪你在步骤 3 中想要提交的内容，Git 在一个名为“索引”（index）的特殊暂存区中维护了树内容的快照。

最初，索引的内容将与 HEAD 的内容相同。因此，显示 HEAD 和索引之间差异的命令 git diff --cached 在那时应该不会产生任何输出。

修改索引很简单

要使用新文件或修改后的文件的内容更新索引，请使用

要从索引和工作树中删除文件，请使用

每一步之后，你都可以验证

始终显示 HEAD 和索引文件之间的差异——这是如果你现在创建提交将提交的内容——并且

显示工作树和索引文件之间的差异。

请注意，git add 总是只将文件的当前内容添加到索引中；对同一文件的进一步更改将被忽略，除非你再次对该文件运行 git add。

当你准备好时，只需运行

Git 将提示你输入提交信息，然后创建新提交。使用以下命令检查以确保它符合你的预期

作为一项特殊快捷方式，

将更新索引中所有已修改或已删除的文件，并一步完成提交。

有许多命令对于跟踪你即将提交的内容很有用

你还可以使用 git-gui[1] 来创建提交、查看索引和工作树文件中的更改，并单独选择要包含在索引中的差异块（通过右键单击差异块并选择“Stage Hunk For Commit”）。

虽然不是必需的，但最好以一行简短（不超过 50 个字符）的更改摘要作为提交信息的开头，后面跟一个空行，然后是更详细的描述。提交信息中直到第一个空行之前的文本被视为提交标题，该标题在整个 Git 中都会使用。例如，git-format-patch[1] 将提交转换为电子邮件，它将标题用作主题行，其余提交内容用作正文。

项目通常会生成你不想用 Git 跟踪的文件。这通常包括构建过程生成的文件或编辑器创建的临时备份文件。当然，不用 Git 跟踪文件只是不对其调用 git add 的问题。但这些未跟踪的文件散落在各处很快就会变得令人烦恼；例如，它们使得 git add . 几乎毫无用处，并且它们会不断出现在 git status 的输出中。

你可以通过在工作目录的顶层创建一个名为 .gitignore 的文件来告诉 Git 忽略某些文件，其内容如下

有关语法的详细说明，请参阅 gitignore[5]。你还可以将 .gitignore 文件放置在工作树中的其他目录中，它们将应用于这些目录及其子目录。.gitignore 文件可以像其他任何文件一样添加到你的仓库中（只需像往常一样运行 git add .gitignore 和 git commit），当排除模式（例如匹配构建输出文件的模式）对克隆你仓库的其他用户也有意义时，这会很方便。

如果你希望排除模式仅影响某些仓库（而不是给定项目的每个仓库），你可以将它们放入你的仓库中名为 .git/info/exclude 的文件，或由 core.excludesFile 配置变量指定的任何文件中。某些 Git 命令也可以直接在命令行上接受排除模式。有关详细信息，请参阅 gitignore[5]。

你可以使用 git-merge[1] 将两个分叉的开发分支重新合并

将分支 branchname 中的开发内容合并到当前分支中。

合并是通过合并自其历史分叉以来 branchname 中所做的更改以及当前分支中直到最新提交所做的更改来完成的。当合并干净完成时，工作树会被合并结果覆盖；当合并导致冲突时，则会被部分合并的结果覆盖。因此，如果你有未提交的更改涉及到与合并受影响的文件相同的文件，Git 将拒绝继续。大多数情况下，你会希望在合并之前提交你的更改，如果你没有这样做，那么 git-stash[1] 可以在你进行合并时将这些更改暂存起来，并在之后重新应用它们。

如果更改足够独立，Git 将自动完成合并并提交结果（或者在快进的情况下重用现有提交，见下文）。另一方面，如果存在冲突——例如，如果同一个文件在远程分支和本地分支中以两种不同的方式被修改——那么你将收到警告；输出可能看起来像这样

冲突标记会留在有问题的文件中，手动解决冲突后，你可以用新内容更新索引并运行 Git commit，就像你通常创建新文件时那样。

如果你使用 gitk 检查结果提交，你将看到它有两个父提交，一个指向当前分支的顶部，另一个指向另一个分支的顶部。

当合并未能自动解决时，Git 会将索引和工作树置于一种特殊状态，为你提供解决合并所需的所有信息。

有冲突的文件在索引中会被特殊标记，因此在你解决问题并更新索引之前，git-commit[1] 将会失败

此外，git-status[1] 会将这些文件列为“未合并”，并且有冲突的文件会添加冲突标记，如下所示

你只需编辑文件来解决冲突，然后

请注意，提交信息将已为你填写了一些关于合并的信息。通常你可以直接使用此默认信息而无需更改，但如果需要，你可以添加自己的额外注释。

以上就是解决简单合并所需了解的全部内容。但 Git 还提供了更多信息来帮助解决冲突

如果你陷入困境并决定放弃一切，你总是可以通过以下方式返回到合并前的状态

或者，如果你已经提交了你想要放弃的合并，

然而，在某些情况下，最后一个命令可能很危险——如果某个你已经提交的提交本身可能已经合并到另一个分支中，则切勿丢弃它，因为这样做可能会使后续合并混淆。

上面没有提到一个特殊情况，它被区别对待。通常，合并会产生一个合并提交，它有两个父提交，分别指向两条被合并的开发线。

然而，如果当前分支是另一个分支的祖先——即当前分支中存在的每个提交都已包含在另一个分支中——那么 Git 只会执行“快进”；当前分支的 HEAD 会向前移动，指向被合并分支的 HEAD，而不会创建任何新提交。

如果你搞砸了工作树，但尚未提交你的错误，你可以使用以下命令将整个工作树恢复到上次提交的状态

如果你做了一个后来希望没有做过的提交，有两种根本不同的方法来解决问题

在大型仓库中，Git 依赖压缩来防止历史信息占用过多的磁盘或内存空间。一些 Git 命令可能会自动运行 git-gc[1]，因此你无需担心手动运行它。但是，压缩大型仓库可能需要一些时间，因此你可能希望显式调用 gc 以避免在不方便时自动启动压缩。

在你克隆仓库并提交了一些自己的更改后，你可能希望检查原始仓库的更新并将其合并到你自己的工作中。

我们已经了解了如何使远程跟踪分支保持最新与 git-fetch[1]，以及如何合并两个分支。因此，你可以使用以下命令合并原始仓库 master 分支的更改

然而，git-pull[1] 命令提供了一种一步完成此操作的方法

实际上，如果你已经检出了 master，那么该分支已通过 git clone 配置为从 origin 仓库的 HEAD 分支获取更改。因此，通常你只需简单地执行以下操作即可完成上述任务

此命令将从远程分支获取更改到你的远程跟踪分支 origin/*，并将默认分支合并到当前分支。

更一般地说，从远程跟踪分支创建的分支将默认从该分支拉取。有关如何控制这些默认值的详细信息，请参阅 branch.<name>.remote 和 branch.<name>.merge 选项在 git-config[1] 中的描述，以及 git-checkout[1] 中 --track 选项的讨论。

除了节省你的按键次数外，git pull 还会通过生成一个默认的提交信息来帮助你，其中记录了你从中拉取的分支和仓库。

（但请注意，在快进的情况下不会创建此类提交；相反，你的分支将仅更新以指向来自上游分支的最新提交。）

git pull 命令也可以将 . 作为“远程”仓库，在这种情况下它只会合并当前仓库中的一个分支；所以命令

大致等价。

如果你只有少量更改，最简单的提交方式可能就是通过电子邮件发送补丁

首先，使用 git-format-patch[1]；例如

将在当前目录中生成一系列编号文件，当前分支中的每个补丁一个文件，但 origin/HEAD 中的除外。

git format-patch 可以包含一个初始的“封面信”。你可以在 format-patch 在提交信息之后但在补丁本身之前放置的三条虚线之后插入对单个补丁的评论。如果你使用 git notes 来跟踪你的封面信材料，git format-patch --notes 将以类似的方式包含提交的注释。

然后你可以将这些导入到你的邮件客户端并手动发送。但是，如果你有大量要一次性发送，你可能更喜欢使用 git-send-email[1] 脚本来自动化该过程。请先咨询你项目的邮件列表，以确定他们提交补丁的要求。

Git 还提供了一个名为 git-am[1]（am 代表“apply mailbox”）的工具，用于导入此类通过电子邮件发送的系列补丁。只需将所有包含补丁的消息按顺序保存到一个邮箱文件，例如 patches.mbox，然后运行

Git 将按顺序应用每个补丁；如果发现任何冲突，它将停止，你可以按照“解决合并”中描述的方式修复冲突。（-3 选项告诉 Git 执行合并；如果你希望它只中止并保持你的树和索引不变，你可以省略该选项。）

一旦索引使用冲突解决的结果进行了更新，只需运行，而无需创建新提交

Git 将为你创建提交并继续从邮箱中应用剩余的补丁。

最终结果将是一系列提交，原始邮箱中的每个补丁对应一个，其作者和提交日志信息均取自包含相应补丁的消息。

向项目提交更改的另一种方法是告诉该项目的维护者使用 git-pull[1] 从你的仓库拉取更改。在“使用 git pull 获取更新”一节中，我们将其描述为从“主”仓库获取更新的方法，但它反向也同样适用。

如果你和维护者都在同一台机器上拥有账户，那么你可以直接从彼此的仓库中拉取更改；接受仓库 URL 作为参数的命令也将接受本地目录名

或 SSH URL

对于开发人员较少的项目，或者用于同步少数私有仓库，这可能就是你所需要的全部。

然而，更常见的方法是维护一个单独的公共仓库（通常在不同的主机上），供其他人从中拉取更改。这通常更方便，并且允许你将私有进行中的工作与公开可见的工作清楚地分离。

你将继续在你的个人仓库中进行日常工作，但会定期将更改从你的个人仓库“推”送到你的公共仓库中，允许其他开发人员从该仓库拉取。因此，在有另一个开发人员拥有公共仓库的情况下，更改的流程如下所示

我们将在以下章节中解释如何进行此操作。

一个具有截断历史的 浅克隆（shallow clone），在只对项目近期历史感兴趣且从上游获取完整历史成本很高时非常有用。

通过指定 git-clone[1] 的 --depth 开关来创建 浅克隆。深度稍后可以使用 git-fetch[1] 的 --depth 开关进行更改，或者使用 --unshallow 恢复完整历史。

在 浅克隆 中进行合并是可行的，只要合并基础（merge base）在近期历史中。否则，这将类似于合并不相关的历史，并可能导致巨大的冲突。这个限制可能会使这种仓库不适合用于基于合并的工作流。

假设你是一个大型项目的贡献者，并且你想添加一个复杂的功能，并以一种让其他开发者容易阅读你的更改、验证其正确性并理解你为什么进行每项更改的方式来呈现它。

如果你将所有更改作为单个补丁（或提交）呈现，他们可能会发现一次消化太多。

如果你向他们展示你工作的完整历史，包括错误、更正和死胡同，他们可能会不知所措。

因此，理想情况通常是生成一系列补丁，使得

我们将介绍一些可以帮助你完成此操作的工具，解释如何使用它们，然后解释由于你正在重写历史可能出现的一些问题。

假设你在远程跟踪分支 origin 上创建了一个分支 mywork，并在其之上创建了一些提交

你尚未将任何内容合并到 mywork 中，因此它只是在 origin 之上的一系列简单线性补丁

上游项目已经完成了一些更有趣的工作，并且 origin 已经向前推进

此时，你可以使用 pull 将你的更改合并回来；结果将创建一个新的合并提交，像这样

然而，如果你更喜欢将 mywork 中的历史保持为简单的提交系列而不包含任何合并，你可以选择使用 git-rebase[1]

这将从 mywork 中移除你的每个提交，暂时将它们保存为补丁（在一个名为 .git/rebase-apply 的目录中），更新 mywork 以指向 origin 的最新版本，然后将每个已保存的补丁应用到新的 mywork。结果将如下所示

在此过程中，它可能会发现冲突。在这种情况下，它会停止并允许你解决冲突；解决冲突后，使用 git add 更新索引内容，然后，不要运行 git commit，只需运行

Git 将继续应用其余的补丁。

在任何时候，你都可以使用 --abort 选项来中止此过程并将 mywork 恢复到你开始变基之前的状态

如果你需要在分支中重新排序或编辑多个提交，使用 git rebase -i 可能会更容易，它允许你在变基期间重新排序和压缩提交，以及标记它们进行单独编辑。有关详细信息，请参阅 使用交互式变基，有关替代方案，请参阅 重新排序或从补丁系列中选择。

我们在 通过重写历史来修复错误 中看到，你可以使用以下命令替换最近的提交

这会将旧提交替换为包含你的更改的新提交，让你有机会首先编辑旧的提交消息。这对于修复你上次提交中的拼写错误，或调整暂存不佳的提交的补丁内容非常有用。

如果你需要修改历史中更深层的提交，可以使用 交互式变基的 edit 指令。

有时你想编辑历史中更深层的提交。一种方法是使用 git format-patch 创建一系列补丁，然后将状态重置到补丁之前

然后根据需要修改、重新排序或删除补丁，然后再使用 git-am[1] 再次应用它们

你也可以使用交互式变基来编辑补丁系列。这与 使用 format-patch 重新排序补丁系列 相同，因此请使用你最喜欢的界面。

将你当前的 HEAD 变基到你想要原样保留的最后一个提交上。例如，如果你想重新排序最后 5 个提交，请使用

这将在你的编辑器中打开一个列表，其中包含执行变基所需的步骤。

如注释中所述，你可以通过编辑列表来重新排序提交、将它们压缩在一起、编辑提交消息等。一旦你满意，保存列表并关闭编辑器，变基将开始。

当 pick 被替换为 edit，或者列表中的某个步骤无法自动解决冲突并需要你帮助时，变基将停止。当你完成编辑和/或解决冲突后，你可以使用 git rebase --continue 继续。如果你觉得情况变得过于复杂，你始终可以使用 git rebase --abort 退出。即使变基完成后，你仍然可以通过使用 reflog 恢复原始分支。

有关此过程和更多技巧的详细讨论，请参阅 git-rebase[1] 的“交互模式”部分。

还有许多其他工具，例如 StGit，它们旨在维护补丁系列。这些超出了本手册的范围。

重写分支历史的主要问题与合并有关。假设有人拉取了你的分支并将其合并到他们的分支中，结果大致如下

然后假设你修改了最后三个提交

如果我们在一个仓库中一起检查所有这些历史，它将看起来像

Git 无法知道新头是旧头的更新版本；它对待这种情况的方式与两个开发者并行独立地对旧头和新头进行工作时完全相同。此时，如果有人试图将新头合并到他们的分支中，Git 将尝试将两条（旧的和新的）开发线合并在一起，而不是尝试用新的替换旧的。结果很可能出乎意料。

你仍然可以选择发布其历史被重写的分支，并且其他人能够拉取这些分支以检查或测试它们可能很有用，但他们不应尝试将此类分支拉入他们自己的工作中。

对于支持正确合并的真正分布式开发，已发布的分支绝不应该被重写。

git-bisect[1] 命令可以正确处理包含合并提交的历史。然而，当它找到的提交是合并提交时，用户可能需要比平时更努力地找出为什么该提交引入了问题。

想象一下这段历史

假设在上方开发线中，存在于 Z 的某个函数的含义在提交 X 处发生了改变。从 Z 到 A 的提交改变了函数的实现和所有存在于 Z 的调用点，以及它们添加的新调用点，以保持一致。在 A 处没有错误。

同时，假设在下方开发线中，某人在提交 Y 处为该函数添加了一个新的调用点。从 Z 到 B 的提交都假定该函数的旧语义，并且调用者和被调用者彼此一致。在 B 处也没有错误。

进一步假设两条开发线在 C 处干净地合并，因此不需要解决冲突。

然而，C 处的代码是损坏的，因为在下方开发线上添加的调用者尚未转换为上方开发线上引入的新语义。因此，如果你只知道 D 是坏的，Z 是好的，并且 git-bisect[1] 将 C 标识为罪魁祸首，你将如何找出问题是由于语义的这种改变？

当 git bisect 的结果是一个非合并提交时，你通常应该能够通过只检查该提交来发现问题。开发者可以通过将他们的更改分解为小的独立提交来简化此过程。然而，在上述情况下这无济于事，因为问题从任何单个提交的检查中都不明显；相反，需要对开发有一个全局的视图。更糟糕的是，有问题的函数中的语义更改可能只是上方开发线中更改的一小部分。

另一方面，如果在 C 处不是合并，而是将 Z 到 B 之间的历史变基到 A 的顶部，你将得到这个线性历史

在 Z 和 D* 之间进行二分查找将命中单个罪魁祸首提交 Y*，并且理解 Y* 为什么损坏可能会更容易。

部分出于这个原因，许多经验丰富的 Git 用户，即使在进行一个大量使用合并的项目时，也会在发布前通过对最新上游版本进行变基来保持历史的线性。

除了使用 git-remote[1]，你还可以选择一次只更新一个分支，并将其存储在本地的任意名称下

第一个参数 origin 只是告诉 Git 从你最初克隆的仓库中抓取。第二个参数告诉 Git 从远程仓库抓取名为 todo 的分支，并将其存储在本地名为 refs/heads/my-todo-work 的位置。

你也可以从其他仓库抓取分支；因此

将创建一个名为 example-master 的新分支，并在其中存储来自给定 URL 仓库中名为 master 的分支。如果你已经有一个名为 example-master 的分支，它将尝试 快进 到 example.com 的 master 分支所指定的提交。更详细地说

在前面的示例中，当更新现有分支时，git fetch 会检查以确保远程分支上的最新提交是你本地分支副本上最新提交的后代，然后才将你的本地分支副本更新为指向新提交。Git 将此过程称为 快进。

快进看起来像这样

在某些情况下，新头可能实际上不是旧头的后代。例如，开发者可能意识到犯了一个严重错误并决定回溯，导致出现以下情况

在这种情况下，git fetch 将失败，并打印出警告。

在这种情况下，你仍然可以强制 Git 更新到新头，如下一节所述。然而，请注意，在上述情况下，这可能意味着丢失标记为 a 和 b 的提交，除非你已经创建了指向它们的自己的引用。

如果 git fetch 失败，因为分支的新头不是旧头的后代，你可以使用以下命令强制更新

请注意 + 符号的添加。或者，你可以使用 -f 标志来强制更新所有抓取的分支，如下所示

请注意，旧版本 example/master 指向的提交可能会丢失，正如我们在上一节中看到的。

我们上面看到，origin 只是一个快捷方式，用于指代你最初克隆的仓库。此信息存储在 Git 配置变量中，你可以使用 git-config[1] 查看

如果你还有其他经常使用的仓库，可以创建类似的配置选项以节省输入；例如，

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

另请注意，上述配置可以通过直接编辑文件 .git/config 而不是使用 git-remote[1] 来执行。

配置远程后，以下三个命令将执行相同的操作

有关上述配置选项的更多详细信息，请参阅 git-config[1]；有关 refspec 语法的更多详细信息，请参阅 git-fetch[1]。

我们已经在 理解历史：提交 中看到，所有提交都存储在一个 40 位的“对象名称”下。实际上，表示项目历史所需的所有信息都存储在具有此类名称的对象中。在每种情况下，名称都是通过对对象内容进行 SHA-1 哈希计算得出的。SHA-1 哈希是一种加密哈希函数。这对我们来说意味着不可能找到两个具有相同名称的不同对象。这有许多优点，其中包括

(有关对象格式和 SHA-1 计算的详细信息，请参阅 对象存储格式。)

有四种不同类型的对象：“blob”、“tree”、“commit”和“tag”。

对象类型的一些更详细信息

索引是一个二进制文件（通常保存在 .git/index 中），包含一个已排序的路径名列表，每个路径名都带有权限和一个 blob 对象的 SHA-1；git-ls-files[1] 可以显示索引的内容：

请注意，在旧的文档中，你可能会看到索引被称为“当前目录缓存”或简称“缓存”。它有三个重要的特性：

因此，索引是一种临时暂存区，其中填充了你正在处理的树。

如果你完全清除索引，只要你拥有它所描述的树的名称，你通常就不会丢失任何信息。

在发布引用子模块的超级项目的更改之前，请务必先发布子模块的更改。如果你忘记发布子模块的更改，其他人将无法克隆仓库：

在较旧的 Git 版本中，很容易忘记在子模块中提交新增或修改的文件，这会悄无声息地导致与不推送子模块更改类似的问题。从 Git 1.7.0 开始，超级项目中的 git status 和 git diff 都会在子模块包含新增或修改文件时将其显示为已修改，以防止意外提交这种状态。git diff 在生成补丁输出或与 --submodule 选项一起使用时，也会在工作树一侧添加 -dirty：

你也不应该将子模块中的分支回溯到超出任何超级项目曾经记录过的提交之外。

如果在未检出分支的情况下在子模块中进行并提交了更改，那么运行 git submodule update 是不安全的。它们将被静默覆盖：

如果你的子模块工作树中有未提交的更改，git submodule update 将不会覆盖它们。相反，你会收到通常的关于无法从脏分支切换的警告。

git-cat-file[1] 命令可以显示任何对象的内容，尽管高级的 git-show[1] 通常更有用。

git-commit-tree[1] 命令允许构建具有任意父级和树的提交。

可以使用 git-write-tree[1] 创建树，并可以通过 git-ls-tree[1] 访问其数据。两个树可以使用 git-diff-tree[1] 进行比较。

标签使用 git-mktag[1] 创建，签名可以使用 git-verify-tag[1] 验证，尽管通常使用 git-tag[1] 更简单。

高级操作，例如 git-commit[1] 和 git-restore[1]，通过在工作树、索引和对象数据库之间移动数据来工作。Git 提供了单独执行这些步骤的低层操作。

通常，所有 Git 操作都在索引文件上进行。有些操作**纯粹**在索引文件上工作（显示索引的当前状态），但大多数操作在索引文件与数据库或工作目录之间移动数据。因此，有四种主要组合：

你可以使用各种辅助工具检查对象数据库和索引中表示的数据。对于每个对象，你可以使用 git-cat-file[1] 来检查对象的详细信息：

显示对象的类型，一旦你知道类型（通常在你找到对象的位置隐含），你可以使用：

来显示其内容。注意！树具有二进制内容，因此有一个特殊的辅助工具用于显示该内容，称为 git ls-tree，它将二进制内容转换为更易于阅读的形式。

查看“提交”对象特别有启发性，因为它们往往很小并且相当自解释。特别是，如果你遵循在 .git/HEAD 中放置顶层提交名称的约定，你可以这样做：

来查看顶层提交是什么。

Git 可以帮助你执行三向合并，通过多次重复合并过程，这又可以用于多向合并。常见的情况是你只进行一次三向合并（协调两条历史线）并提交结果，但如果你愿意，你可以一次性合并多个分支。

要执行三向合并，你需要从你想要合并的两个提交开始，找到它们最近的共同父级（第三个提交），然后比较与这三个提交对应的树。

要获取合并的“基础”，请查找两个提交的共同父级：

这会打印出它们都基于的提交名称。你现在应该查找这些提交的树对象，这可以通过以下方式轻松完成：

因为树对象信息总是提交对象中的第一行。

一旦你知道要合并的三棵树（一棵“原始”树，也就是共同树，以及两棵“结果”树，也就是你想合并的分支），你就可以将“合并”读取到索引中。如果它必须丢弃你旧的索引内容，它会发出警告，所以你应该确保你已经提交了这些内容——事实上，你通常总是会根据你的最后一次提交进行合并（无论如何，这应该与你当前索引中的内容匹配）。

要执行合并，请执行：

这将在索引文件中直接为你执行所有琐碎的合并操作，你只需使用 git write-tree 写入结果。

遗憾的是，许多合并并非微不足道。如果有文件被添加、移动或删除，或者如果两个分支都修改了同一个文件，你将得到一个包含“合并条目”的索引树。这样的索引树无法写入树对象，你必须在使用其他工具解决任何此类合并冲突后，才能写入结果。

你可以使用 git ls-files --unmerged 命令检查此类索引状态。示例：

git ls-files --unmerged 命令的每行输出都以 blob 模式位、blob SHA-1、阶段号和文件名开头。阶段号是 Git 表示其来源树的方式：阶段 1 对应于 $orig 树，阶段 2 对应于 HEAD 树，阶段 3 对应于 $target 树。

前面我们提到，简单的合并是在 git read-tree -m 内部完成的。例如，如果文件从 $orig 到 HEAD 或 $target 没有变化，或者如果文件从 $orig 到 HEAD 以及从 $orig 到 $target 的变化方式相同，那么最终结果显然是 HEAD 中的内容。上述示例表明，文件 hello.c 从 $orig 到 HEAD 以及从 $orig 到 $target 的变化方式不同。你可以通过在你喜欢的 3-way 合并程序（例如 diff3、merge 或 Git 自带的 merge-file）上，自行处理来自这三个阶段的 blob 对象来解决此问题，如下所示：

这会将合并结果留在 hello.c~2 文件中，如果存在冲突，还会带有冲突标记。在验证合并结果合理后，你可以通过以下方式告诉 Git 此文件的最终合并结果：

当一个路径处于“未合并”状态时，对该路径运行 git update-index 会告诉 Git 将该路径标记为已解决。

以上是 Git 最底层合并的描述，旨在帮助你理解其内部概念上发生了什么。实际上，没有人，甚至 Git 本身，会为此运行三次 git cat-file。有一个 git merge-index 程序，它将阶段提取到临时文件，并在此文件上调用一个“合并”脚本：

更高级别的 git merge -s resolve 就是用这种方式实现的。

所有对象都具有静态确定的“类型”，用于标识对象的格式（即如何使用它，以及它如何引用其他对象）。目前有四种不同的对象类型：“blob”、“tree”、“commit”和“tag”。

无论对象类型如何，所有对象都共享以下特性：它们都使用 zlib 进行压缩，并带有一个头部，该头部不仅指定了它们的类型，还提供了对象中数据的大小信息。值得注意的是，用于命名对象的 SHA-1 散列是原始数据加上此头部的散列，因此 sha1sum file 不会匹配 file 的对象名称（最早的 Git 版本散列方式略有不同，但结论仍然相同）。

以下是一个简短的示例，演示如何手动生成这些散列：

假设有一个包含简单内容的小文本文件：

现在我们可以手动生成 Git 会用于此文件的散列：

可以使用 git hash-object 验证此手动构建的散列，该命令当然会隐藏头部的添加过程：

因此，对象的通用一致性总是可以独立于对象的内容或类型进行测试：所有对象都可以通过验证 (a) 它们的散列与文件内容匹配，以及 (b) 对象成功解压为字节流，形成 <ascii-type-without-space> + <space> + <ascii-decimal-size> + <byte\0> + <binary-object-data> 序列来验证。

结构化对象可以进一步验证其结构和与其他对象的连接性。这通常通过 git fsck 程序完成，该程序生成所有对象的完整依赖图，并验证它们的内部一致性（除了仅通过散列验证其表面一致性）。

对于新开发者来说，在 Git 源代码中找到方向并非总是容易。本节为你提供一些指导，告诉你从何开始。

一个好的起点是查看初始提交的内容：

初始修订奠定了 Git 今天几乎所有内容的基础（尽管细节在某些地方可能有所不同），但它足够小，可以一口气读完。

请注意，自该修订以来，术语已发生变化。例如，该修订中的 README 使用“changeset”一词来描述我们现在所说的提交。

此外，我们不再称之为“cache”（缓存），而是“index”（索引）；但是，该文件仍然名为 read-cache.h。

如果你理解了初始提交中的概念，你应该查看一个较新的版本，并浏览 read-cache-ll.h、object.h 和 commit.h。

早期，Git（遵循 UNIX 传统）是一组极其简单的程序，你在脚本中使用它们，将一个程序的输出通过管道传递给另一个。这对初始开发很有利，因为它更容易测试新事物。然而，最近这些部分中的许多已经变成了内置命令，并且一些核心部分已经“库化”，即为了性能、可移植性以及避免代码重复而被放入 libgit.a。

到目前为止，你已经知道索引是什么（并且在 read-cache-ll.h 中找到相应的数据结构），并且知道只有几种对象类型（blobs、trees、commits 和 tags），它们都从 struct object 继承其通用结构，后者是它们的第一个成员（因此，你可以例如将 (struct object *)commit 强制转换为与 &commit->object 相同的效果，即获取对象名称和标志）。

现在是休息一下，让这些信息消化吸收的好时机。

下一步：熟悉对象命名。阅读命名提交。有很多方式来命名一个对象（不仅仅是修订版！）。所有这些都在 sha1_name.c 中处理。快速查看函数 get_sha1()。很多特殊处理都是由诸如 get_sha1_basic() 之类的函数完成的。

这只是为了让你进入 Git 最库化的部分：修订遍历器（revision walker）。

基本上，git log 的初始版本是一个 shell 脚本：

这意味着什么？

git rev-list 是修订遍历器的原始版本，它总是将修订列表打印到标准输出。它仍然可用，并且需要如此，因为大多数新的 Git 命令都是从使用 git rev-list 的脚本开始的。

git rev-parse 现在不再那么重要了；它仅用于过滤出与脚本调用的不同底层命令相关的选项。

git rev-list 所做的主要工作包含在 revision.c 和 revision.h 中。它将选项封装在一个名为 rev_info 的结构体中，该结构体控制如何以及遍历哪些修订版等。

git rev-parse 的原始工作现在由函数 setup_revisions() 完成，它解析修订版和修订遍历器的常用命令行选项。这些信息存储在结构体 rev_info 中，供以后使用。调用 setup_revisions() 后，你可以进行自己的命令行选项解析。之后，你必须调用 prepare_revision_walk() 进行初始化，然后可以使用函数 get_revision() 逐个获取提交。

如果你对修订遍历过程的更多细节感兴趣，只需查看 cmd_log() 的首次实现；调用 git show v1.3.0~155^2~4 并向下滚动到该函数（请注意，你不再需要直接调用 setup_pager()）。

如今，git log 是一个内置命令，这意味着它包含在命令 git 中。一个内置命令的源代码方面是：

有时，一个源文件中包含多个内置命令。例如，cmd_whatchanged() 和 cmd_log() 都位于 builtin/log.c 中，因为它们共享相当多的代码。在这种情况下，那些不以其所在 .c 文件名命名的命令必须在 Makefile 的 BUILT_INS 中列出。

git log 在 C 语言中看起来比原始脚本复杂，但这带来了更大的灵活性和性能。

在这里再次暂停一下是个不错的时机。

第三课是：研究代码。真的，这是了解 Git 组织结构的最好方法（在你了解基本概念之后）。

那么，思考一下你感兴趣的事情，比如：“如何仅通过 blob 的对象名称来访问它？”第一步是找到一个可以实现此功能的 Git 命令。在本例中，它要么是 git show，要么是 git cat-file。

为了清晰起见，我们继续使用 git cat-file，因为它：

因此，查看 builtin/cat-file.c，搜索 cmd_cat_file() 并查看它的作用。

我们跳过显而易见的细节；这里唯一真正有趣的部分是对 get_sha1() 的调用。它尝试将 argv[2] 解释为对象名称，如果它引用了当前仓库中存在的对象，它会将生成的 SHA-1 写入变量 sha1。

这里有两点值得注意：

你会在整个代码中看到这两种情况。

现在，重点来了：

这就是你读取 blob（实际上，不仅是 blob，而是任何类型的对象）的方式。要了解函数 read_object_with_reference() 实际如何工作，请查找其源代码（例如在 Git 仓库中运行 git grep read_object_with | grep ":[a-z]"），然后阅读源代码。

要了解如何使用结果，只需继续阅读 cmd_cat_file()：

有时，你不知道在哪里查找某个特性。在许多此类情况下，通过搜索 git log 的输出，然后 git show 相应的提交，会有所帮助。

示例：如果你知道 git bundle 有一些测试用例，但想不起来它在哪里（是的，你可以运行 git grep bundle t/，但这并不能说明重点！）：

在分页器（less）中，只需搜索“bundle”，回溯几行，你就会看到它在提交 18449ab0 中。现在只需复制此对象名称，并将其粘贴到命令行中：

就是这样。

另一个示例：找出如何将某个脚本变为内置命令：

你看，Git 实际上是了解 Git 自身源代码的最佳工具！

从 tarball 创建

从远程仓库创建

除了基于当前 HEAD 创建新分支（默认行为）外，还可以使用

同时创建并切换到新分支

更新并检查你克隆自的仓库中的分支

从不同的仓库抓取一个分支，并在你的仓库中为其指定一个新名称

保留你经常使用的仓库列表

搜索回归

确保 Git 知道谁是负责人

选择要包含在下一次提交中的文件内容，然后进行提交

或者，一步完成提交的准备和创建

导入或导出补丁

在不同的Git仓库中抓取一个分支，然后合并到当前分支

在合并到当前分支之前，将抓取的分支存储到本地分支

在本地分支上创建提交后，使用你的提交更新远程分支

当远程分支和本地分支都命名为“test”时

常用远程仓库的快捷方式版本

检查损坏

重新压缩，移除未使用的垃圾

这是一项正在进行的工作。

基本要求

考虑如何创建一个清晰的章节依赖图，这将允许人们在不必阅读所有中间内容的情况下，直接跳转到重要主题。

扫描Documentation/以查找遗漏的其他内容；特别是：

扫描电子邮件存档以查找遗漏的其他内容

扫描手册页，查看是否有任何内容假设了比本手册提供的更多背景知识。

添加更多好的示例。完全由“食谱”式示例组成的章节可能是一个好主意；也许可以把“高级示例”部分作为章节的标准结尾部分？

在适当的地方包含到词汇表的交叉引用。

添加一个关于与其他版本控制系统（包括CVS、Subversion以及单纯的发布tarball系列导入）协作的章节。

编写一个关于使用底层命令和编写脚本的章节。

替代方案、克隆 -reference 等。

更多关于从仓库损坏中恢复的信息。参见：https://lore.kernel.org/git/Pine.LNX.4.64.0702272039540.12485@woody.linux-foundation.org/ https://lore.kernel.org/git/Pine.LNX.4.64.0702141033400.3604@woody.linux-foundation.org/