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

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

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

clone 命令创建一个以项目命名的新目录（在上面的示例中为git或linux）。 进入此目录后，您将看到它包含项目文件的副本，称为工作树，以及一个名为.git的特殊顶层目录，其中包含有关项目历史的所有信息。

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

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

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

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

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

标签应始终指向项目的同一版本，而 head 应随着开发的进行而前进。

创建一个指向这些版本之一的新分支头，并使用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 检查引用的完整路径列表，以及当存在具有相同简写名称的多个引用时，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 现在与任何分支分离，并直接指向可从 “master” 访问但不能从 v2.6.18 访问的提交（提交 ID 为 65934）。编译并测试它，看看它是否崩溃。假设它确实崩溃了。然后

检出一个较旧的版本。像这样继续，在每个阶段告诉 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] 手册页的 “SPECIFYING REVISIONS” 部分。一些例子

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

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

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

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 在一个称为“索引”的特殊暂存区域中维护树内容的快照。

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

修改索引很容易

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

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

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

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

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

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

准备好后，只需运行

Git 将提示你输入提交消息，然后创建新的提交。 检查以确保它看起来符合你的预期

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

将更新索引，其中包含你已修改或删除的任何文件，并创建一个提交，所有操作都在一个步骤中完成。

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

你还可以使用 git-gui[1] 创建提交，查看索引和工作树文件中的更改，并单独选择 diff hunk 以包含在索引中（通过右键单击 diff hunk 并选择“暂存提交 Hunk”）。

虽然不是必需的，但最好以一行简短的（不超过 50 个字符）行开始提交消息，总结更改，后跟一个空行，然后是更详尽的描述。 提交消息中直到第一个空行的文本被视为提交标题，并且该标题在整个 Git 中使用。 例如，git-format-patch[1] 将提交转换为电子邮件，并在 Subject 行中使用标题，并在正文中使用提交的其余部分。

一个项目通常会生成你*不想*用 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 提交。

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

当合并无法自动解决时，Git 会将索引和工作目录置于一种特殊状态，为您提供帮助解决合并所需的所有信息。

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

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

您需要做的就是编辑文件以解决冲突，然后

请注意，提交信息已经为您填写了一些关于合并的信息。通常您可以直接使用此默认消息，但如果需要，您可以添加自己的注释。

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

如果您遇到困难，决定放弃并抛弃整个烂摊子，您始终可以使用以下命令返回到合并前的状态：

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

但是，最后一条命令在某些情况下可能很危险——如果已经提交的提交可能已经被合并到另一个分支，则永远不要放弃该提交，因为这样做可能会使进一步的合并感到困惑。

上面没有提到一个特殊情况，即快进合并，它的处理方式不同。通常，合并会导致合并提交，具有两个父提交，一个指向要合并的两个开发线路中的每一个。

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

如果您弄乱了工作目录，但尚未提交您的错误，您可以使用以下命令将整个工作目录返回到上次提交的状态：

如果您进行了一次提交，后来希望没有进行过，那么有两种根本不同的方法来解决该问题。

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

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

我们已经看到了 如何使用 git-fetch[1] 更新远程跟踪分支，以及如何合并两个分支。 因此，您可以使用以下命令合并来自原始仓库的 master 分支的更改：

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

事实上，如果您已检出 master，那么此分支已被 git clone 配置为从原始仓库的 HEAD 分支获取更改。 因此，通常您可以通过一个简单的命令来完成上述操作：

此命令会将来自远程分支的更改提取到您的远程跟踪分支 origin/*，并将默认分支合并到当前分支中。

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

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

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

也可以将 git pull 命令的 "remote" 仓库指定为 .，在这种情况下，它只是从当前仓库合并一个分支；因此，以下命令：

大致等效。

如果您只有一些更改，那么提交它们的最简单方法可能只是通过电子邮件将它们作为补丁发送。

首先，使用 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：

对于开发者很少的项目，或者对于同步一些私有仓库，这可能就是您所需要的全部。

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

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

我们在以下各节中解释如何执行此操作。

浅克隆 及其截断的历史记录，在人们只对项目的最近历史感兴趣，并且从上游获取完整历史记录的成本很高时非常有用。

浅克隆 是通过指定 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 返回到你开始 rebase 之前的状态

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

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

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

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

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

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

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

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

这将打开你的编辑器，其中包含执行 rebase 所需的步骤列表。

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

rebase 将在 pick 被替换为 edit 时停止，或者当列表中的某个步骤未能机械地解决冲突并需要你的帮助时停止。完成编辑和/或解决冲突后，你可以使用 git rebase --continue 继续。如果你觉得事情变得太棘手，你始终可以使用 git rebase --abort 退出。即使在 rebase 完成后，你仍然可以使用 reflog 恢复原始分支。

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

还有许多其他工具，例如 StGit，其存在目的是维护补丁系列。这些不在本手册的范围内。

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

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

如果我们在一个存储库中一起检查所有这些历史记录，它将如下所示

Git 无法知道新的 head 是旧 head 的更新版本；它以与两个开发人员独立并行地在旧 head 和新 head 上完成工作相同的方式处理这种情况。此时，如果有人尝试将新的 head 合并到他们的分支中，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 之间的历史记录 rebase 到 A 之上，你将获得这个线性历史记录

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

部分出于这个原因，许多经验丰富的 Git 用户，即使在处理其他方面合并繁重的项目时，也会通过在发布之前针对最新的上游版本进行 rebase 来保持历史记录的线性。

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

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

你也可以从其他仓库获取分支；所以

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

在前面的例子中，当更新现有分支时，git fetch 会检查远程分支上最近的提交是否是你分支副本上最近提交的后代，然后才将你的分支副本更新到新的提交。 Git 将此过程称为 快进。

快进看起来像这样

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

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

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

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

注意添加了 + 符号。 或者，你可以使用 -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 都会将包含新的或修改的文件的子模块显示为已修改，以防止意外提交此类状态。当生成补丁输出或与 --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，它将二进制内容转换为更易于阅读的形式。

查看 "commit" 对象特别有指导意义，因为这些对象往往很小且相当容易理解。特别是，如果你遵循将顶部提交名称放在 .git/HEAD 中的约定，你可以执行

来查看顶部提交是什么。

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

要执行三路合并，你首先需要两个要合并的提交，找到它们最近的共同父项（第三个提交），然后比较对应于这三个提交的树。

要获得合并的 "base"，请查找两个提交的共同父项

这会打印出它们都基于的提交的名称。你现在应该查找这些提交的树对象，你可以很容易地使用以下命令来完成

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

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

要进行合并，请执行

这将直接在索引文件中为你执行所有简单的合并操作，你可以直接使用 git write-tree 将结果写出。

遗憾的是，许多合并并非易事。如果存在已添加、移动或删除的文件，或者两个分支都修改了同一个文件，你将得到一个包含 "merge entries" 的索引树。这样的索引树不能写出到树对象，你必须使用其他工具解决任何此类合并冲突，然后才能写出结果。

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

git ls-files --unmerged 输出的每一行都以 blob 模式位、blob SHA-1、stage number 和文件名开头。stage number 是 Git 用于说明它来自哪个树的方式：stage 1 对应于 $orig 树，stage 2 对应于 HEAD 树，stage 3 对应于 $target 树。

之前我们说过简单的合并是在 git read-tree -m 内部完成的。例如，如果文件从 $orig 到 HEAD 或 $target 没有更改，或者文件以相同的方式从 $orig 更改为 HEAD 和从 $orig 更改为 $target，显然最终结果是 HEAD 中的内容。上面的例子表明文件 hello.c 以不同的方式从 $orig 更改为 HEAD 和从 $orig 更改为 $target。你可以通过运行你最喜欢的 3 路合并程序来解决这个问题，例如 diff3、merge 或 Git 自己的 merge-file，针对这三个阶段的 blob 对象，像这样

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

当路径处于 "unmerged" 状态时，为该路径运行 git update-index 会告诉 Git 将该路径标记为已解决。

以上是对 Git 合并在最低级别的描述，旨在帮助你理解在底层发生了什么概念上的事情。在实践中，没有人，甚至 Git 本身，会为此运行三次 git cat-file。有一个 git merge-index 程序会将各个阶段提取到临时文件中，并在其上调用 "merge" 脚本

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

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

无论对象类型如何，所有对象都具有以下特征：它们都使用 zlib 进行解压缩，并且具有一个标头，该标头不仅指定了它们的类型，还提供了有关对象中数据的大小信息。值得注意的是，用于命名对象的 SHA-1 哈希是原始数据加上此标头的哈希，因此 file 的 sha1sum *文件* 与 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" 一词来描述我们现在称为 commit 的内容。

此外，我们不再称其为 "cache"，而是称其为 "index"；但是，该文件仍称为 read-cache.h。

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

在早期，Git（按照 UNIX 的传统）是一堆非常简单的程序，你可以在脚本中使用这些程序，将一个程序的输出通过管道传输到另一个程序。事实证明，这对初始开发有利，因为测试新事物更容易。然而，最近许多这些部分已经变成了内置程序，并且一些核心内容已经被 "libified"，即放入 libgit.a 中，以提高性能、可移植性，并避免代码重复。

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

现在是休息一下，让这些信息沉淀下来的好时机。

下一步：熟悉对象命名。阅读 命名提交。有很多方法可以命名对象（不仅仅是修订版！）。所有这些都在 sha1_name.c 中处理。快速浏览一下函数 get_sha1()。许多特殊处理由 get_sha1_basic() 或类似函数完成。

这只是为了让你进入 Git 最 libified 的部分：修订版遍历器。

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

这意味着什么？

git rev-list 是修订版遍历器的原始版本，它总是将修订版列表打印到 stdout。它仍然可以正常工作，并且需要这样做，因为大多数新的 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）的部分。

编写一个关于使用管道和编写脚本的章节。

备用方案、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/