在阅读本手册时，拥有一个用于实验的 Git 仓库会很有用。

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

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

clone 命令会创建一个以项目命名的新目录（在上面的示例中为 git 或 linux）。在你 cd 进入该目录后，你会发现它包含项目文件的副本，称为 工作区 (working tree)，以及一个名为 .git 的特殊顶层目录，其中包含有关项目历史的所有信息。

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

这些快照并不一定都按照从旧到新的单一线条排列；相反，工作可以沿着平行的开发线路同时进行，这些开发线路被称为 分支 (branches)，它们可能会合并或分叉。

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

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

大多数项目还会使用 标签 (tags)。标签与 heads 一样，都是指向项目历史的引用，可以使用 git-tag[1] 命令列出

标签通常始终指向项目的同一个版本，而 heads 则随着开发的推进而向前移动。

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

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

如果你决定改看 2.6.17 版本，可以使用以下命令修改当前分支使其指向 v2.6.17：

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

项目历史中的每一次更改都由一个提交表示。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 处于“分离 (detached)”状态。

这是一种在无需为新分支命名的情况下检出特定版本的简便方法。如果你后来决定保留，仍然可以为此版本创建一个新分支（或标签）。

你在克隆时创建的 "master" 分支是你所克隆的仓库中 HEAD 的副本。不过，那个仓库可能还有其他分支，你的本地仓库会保留跟踪这些远程分支的分支，称为远程跟踪分支 (remote-tracking branches)，你可以使用 git-branch[1] 的 -r 选项查看它们

在此示例中，"origin" 被称为远程仓库，简称 "remote"。从我们的角度来看，该仓库的分支被称为“远程分支”。上面列出的远程跟踪分支是在克隆时基于远程分支创建的，并将通过 git fetch（以及 git pull）和 git push 进行更新。详情请参阅 使用 git fetch 更新仓库。

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

你也可以直接检出 origin/todo 来查看它或编写一个临时补丁。参见 分离 HEAD。

请注意，名称 "origin" 只是 Git 默认用来引用你所克隆的仓库的名称。

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

如果同时存在同名的标签和分支，全名偶尔会很有用。

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

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

有关 Git 检查引用的完整路径列表，以及当存在多个具有相同缩写名称的引用时它决定选择哪一个的顺序，请参阅 gitrevisions[7] 的 "SPECIFYING REVISIONS" 章节。

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

不带参数的 git-fetch 命令将把所有远程跟踪分支更新为原始仓库中发现的最新版本。它不会触动你的任何本地分支——甚至不会触动克隆时为你创建的 "master" 分支。

你还可以使用 git-remote[1] 跟踪来自非克隆来源仓库的分支

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

如果你稍后运行 git fetch <remote>，该命名 <remote> 的远程跟踪分支将会更新。

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

这就是导致 Git 跟踪远程分支的原因；你可以通过文本编辑器编辑 .git/config 来修改或删除这些配置选项。（详情见 git-config[1] 的 "CONFIGURATION FILE" 章节。）

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

如果你在此时运行 git branch，你会发现 Git 暂时将你移到了 "(no branch)"。HEAD 现在脱离了任何分支，直接指向一个提交（提交 ID 为 65934），该提交可从 "master" 到达，但不可从 v2.6.18 到达。编译并测试它，看它是否崩溃。假设它确实崩溃了。那么执行

检出一个更旧的版本。继续这样做，在每个阶段告诉 Git 它给你的版本是好是坏，并注意每次要测试的版本数量大约会减少一半。

在大约 13 次测试后（在本例中），它将输出“有罪”提交的 ID。然后你可以使用 git-show[1] 查看该提交，查明是谁写的，并将 bug 报告连同提交 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] 手册页中的 "SPECIFYING REVISIONS" 部分。一些示例

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

除了 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] 的 "CONFIGURATION FILE" 部分。该文件是纯文本，因此你也可以使用你喜欢的编辑器进行编辑。

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

如果你有一些初始内容（比如一个压缩包）

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

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

开始时，索引的内容将与 HEAD 的内容完全相同。因此，显示 HEAD 与索引之间差异的命令 git diff --cached 在此时不应产生任何输出。

修改索引很容易

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

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

在每个步骤之后，你都可以验证

始终显示 HEAD 与索引文件之间的差异——这就是如果你现在创建提交所要提交的内容——以及

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

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

准备就绪后，只需运行

Git 会提示你输入提交信息，然后创建新提交。使用以下命令确保它看起来符合预期

作为一个特殊的快捷方式，

将使用你修改或删除的任何文件更新索引并创建一个提交，所有操作一步完成。

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

你还可以使用 git-gui[1] 来创建提交、查看索引和工作树文件中的更改，并单独选择差异块 (diff hunks) 以包含在索引中（通过右键单击差异块并选择 "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 将自动完成合并并提交结果（或者在 快进 (fast-forward) 的情况下复用现有提交，见下文）。另一方面，如果存在冲突——例如，如果同一个文件在远程分支和本地分支中以两种不同的方式被修改——那么你会收到警告；输出可能看起来像这样

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

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

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

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

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

你所需要做的就是编辑文件以解决冲突，然后执行

请注意，提交信息中已经为你填入了一些关于合并的信息。通常你可以直接使用这个默认消息，但如果需要，也可以添加你自己的额外说明。

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

如果你陷入困境并决定干脆放弃并扔掉整个烂摊子，你随时可以通过以下命令返回到合并前的状态

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

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

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

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

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

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

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

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

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

然而，git-pull[1] 命令提供了一种一步到位的方法

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

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

更一般地说，从远程跟踪分支创建的分支默认将从该分支 pull。请参阅 git-config[1] 中 branch.<name>.remote 和 branch.<name>.merge 选项的描述，以及 git-checkout[1] 中 --track 选项的讨论，以了解如何控制这些默认设置。

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

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

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

大致等效。

如果你只有少量更改，提交它们的最简单方法可能是将其作为电子邮件补丁发送

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

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

git format-patch 可以包含一个初始的“封面信 (cover letter)”。你可以在三横线行之后插入关于单个补丁的评论，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 恢复完整历史。

只要合并基准在近期历史中，在 浅克隆 内合并就能正常工作。否则，这就像合并无关的历史一样，可能会导致巨大的冲突。这种限制可能使此类仓库不适合用于基于合并的工作流。

假设你是一个大型项目的贡献者，你想添加一个复杂的功能，并将其呈现给其他开发人员，以便他们轻松阅读你的更改，验证其正确性，并理解你进行每次更改的原因。

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

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

因此，理想的做法通常是制作一系列补丁，使得

我们将介绍一些可以帮助你做到这一点的工具，解释如何使用它们，然后解释由于重写历史可能产生的一些问题。

假设你在远程跟踪分支 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] 的“INTERACTIVE MODE”部分。

还有许多其他工具（如 StGit）是为维护补丁系列而存在的。这些超出了本手册的范围。

重写分支历史的主要问题与合并有关。假设有人获取了你的分支并将其合并到他们的分支中，结果类似于这样

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

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

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

你仍然可以选择发布历史记录被重写的分支，其他人能够获取这些分支以便检查或测试可能是有用的，但他们不应尝试将此类分支拉取（pull）到他们自己的工作中。

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

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 将此过程称为快进 (fast-forward)。

快进看起来像这样

在某些情况下，新的 head 可能不是旧 head 的后代。例如，开发人员可能意识到犯了一个严重的错误并决定回溯，导致如下情况

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

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

如果由于分支的新 head 不是旧 head 的后代导致 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] 可以显示索引的内容

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

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

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

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

在旧版本的 Git 中，很容易忘记在子模块中提交新文件或修改过的文件，这会悄悄地导致与不推送子模块更改类似的问题。从 Git 1.7.0 开始，父项目中的 git status 和 git diff 都会在子模块包含新文件或修改过的文件时将其显示为已修改，以防止意外提交此类状态。在生成补丁输出或使用 --submodule 选项时，git diff 也会在工作树端添加 -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 可以帮助你执行三方合并，通过多次重复合并过程，三方合并反过来又可以用于多方合并。通常情况是你只进行一次三方合并（协调两条历史线）并提交结果，但如果你愿意，也可以一次性合并多个分支。

要执行三方合并，你从要合并的两个提交开始，找到它们最近的共同父提交（第三个提交），并比较对应于这三个提交的树。

要获得合并的“基准 (base)”，请查找两个提交的共同父提交：

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

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

一旦你知道了要合并的三个树（一个是“原始”树，即共同树，以及两个“结果”树，即你要合并的分支），你就可以将“合并”读取到索引中。如果要丢弃旧的索引内容，此操作会发出抱怨，因此你应该确保已提交这些内容——事实上，你通常总是针对最后一次提交进行合并（因此该提交应与当前索引中的内容相匹配）。

要进行合并，请执行：

这将直接在索引文件中为你执行所有琐碎的合并操作，你可以直接使用 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 以不同方式发生了变化。你可以通过对这三个阶段的 blob 对象运行你最喜欢的三方合并程序（例如 diff3、merge 或 Git 自己的 merge-file）来亲自解决此问题，如下所示：

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

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

以上是对最底层 Git 合并过程的描述，旨在帮助您从概念上理解底层发生的机制。在实践中，没有人（甚至 Git 自身）会为此运行三次 git cat-file。存在一个 git merge-index 程序，它会将暂存级（stages）提取到临时文件中，并在其上调用“合并”脚本

而更高层级的 git merge -s resolve 正是基于此实现的。

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

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

以下是一个简短的示例，演示了如何手动生成这些哈希值

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

我们现在可以手动生成 Git 为该文件使用的哈希值

这个手动构建的哈希值可以使用 git hash-object 进行验证，它当然会隐藏添加头部的过程

因此，对象的一般一致性始终可以独立于内容或对象类型进行测试：所有对象都可以通过验证以下两点来生效：(a) 它们的哈希值与文件内容匹配，以及 (b) 对象成功解压（inflate）为一系列字节流，其序列形式为 <ascii类型(不含空格)> + <空格> + <ascii十进制大小> + <byte\0> + <二进制对象数据>。

结构化对象可以进一步验证其结构以及与其他对象的连接性。这通常使用 git fsck 程序完成，该程序会生成所有对象的完整依赖图，并验证其内部一致性（除了通过哈希验证其表面一致性之外）。

新开发者想要在 Git 源代码中找到方向并不总是那么容易。本节提供了一些指导，告诉您从哪里开始。

一个好的起点是查看初始提交的内容，使用

初始版本为 Git 今天拥有的一切奠定了基础（尽管某些地方的细节可能有所不同），但它的规模足够小，可以在一次阅读中读完。

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

此外，我们现在不再称其为“cache”，而是称为“index”；然而，头文件仍然叫做 read-cache.h。

如果您掌握了初始提交中的思想，您应该查看较新的版本并浏览 read-cache-ll.h、object.h 和 commit.h。

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

到现在，您已经知道索引是什么了（并在 read-cache-ll.h 中找到相应的数据结构），并且知道只有几种对象类型（blob、tree、commit 和 tag），它们从作为其第一个成员的 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 不再那么重要了；它以前仅用于过滤掉与脚本调用的不同底层命令（plumbing）相关的选项。

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_show() 和 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，还可以是任何类型的对象）。要了解函数 odb_read_object_peeled() 实际是如何工作的，请找到它的源代码（在 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 为基础创建新分支（默认行为），而是使用

同时创建并切换到新分支

更新并检查来自您所克隆的仓库的分支

从不同的仓库获取分支，并在您的仓库中给它起个新名字

维护一个您经常使用的仓库列表

搜索回归（regressions）

确保 Git 知道责任归属（追责）

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

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

导入或导出补丁

获取另一个 Git 仓库中的分支，然后合并到当前分支

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

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

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

针对常用远程仓库的简写版本

检查损坏

重新压缩，清除不使用的废弃物

这是一个正在完善中的工作。

基本要求：

考虑如何创建一个清晰的章节依赖图，以便人们能够直接跳转到重要主题，而不必阅读中间的所有内容。

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

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

扫描帮助页 (man pages)，看看是否有任何页面假设了比本手册提供的更多的背景知识。

添加更多好的示例。包含纯菜谱式示例的整个章节可能是一个好主意；也许将“高级示例”部分作为一个标准的章末部分？

在适当的地方加入对术语表的交叉引用。

添加一个关于与其他版本控制系统（包括 CVS、Subversion）配合使用以及仅导入系列发布压缩包的部分。

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

备用仓库 (Alternates)、clone -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/