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

最佳方法是使用 git-clone[1] 命令下载现有存储库的副本。如果您还没有项目，以下是一些有趣的示例

对于大型项目，初始克隆可能需要花费较长时间，但您只需要克隆一次。

clone 命令会创建一个以项目名称命名的新目录（在上面的示例中为 git 或 linux）。在您进入此目录后，您将看到它包含项目文件的副本，称为 工作树，以及一个名为 .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 的副本。但是，该仓库可能还包含其他分支，并且你的本地仓库会保留跟踪这些远程分支的每个分支，称为远程跟踪分支，你可以使用 -r 选项查看 git-branch[1]

在这个例子中，“origin”被称为远程仓库，或简称“远程”。从我们的角度来看，这个仓库的分支称为“远程分支”。上面列出的远程跟踪分支是在克隆时根据远程分支创建的，并将通过 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 已将你临时移至“(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]手册页的“指定修订版本”部分。一些示例

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

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

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

修改索引很容易

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

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

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

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

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

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

准备好后，只需运行

Git将提示您输入提交消息，然后创建新的提交。使用以下命令检查它是否符合您的预期

作为特殊快捷方式，

将使用您修改或删除的任何文件更新索引，并一步创建提交。

许多命令可用于跟踪您即将提交的内容

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

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

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

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

有关语法的详细说明，请参阅 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 只执行“快进”；当前分支的头部将向前移动以指向合并分支的头部，而不会创建任何新的提交。

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

如果您进行了后来希望自己没有进行的提交，则有两种根本不同的方法可以解决此问题

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

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

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

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

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

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

更一般地，从远程跟踪分支创建的分支将默认从该分支拉取。请参阅 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 可以包含一个初始的“封面信”。您可以在 format-patch 在提交消息之后但在补丁本身之前放置的三条虚线之后插入有关各个补丁的注释。如果您使用 git notes 跟踪您的封面信材料，git format-patch --notes 将以类似的方式包含提交的注释。

然后，您可以将这些导入您的邮件客户端并手动发送。但是，如果您要一次发送很多内容，您可能更愿意使用 git-send-email[1] 脚本来自动化此过程。首先咨询项目的邮件列表以确定他们提交补丁的要求。

Git 还提供了一个名为 git-am[1]（am 代表“应用邮箱”）的工具，用于导入此类通过电子邮件发送的补丁系列。只需按顺序将所有包含补丁的消息保存到一个邮箱文件中，例如 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 返回到开始重新设置基准之前所处的状态

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

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

这将用一个新的提交替换旧的提交，其中包含你的更改，让你有机会首先编辑旧的提交消息。这对于修复上次提交中的错别字或调整分段提交的补丁内容很有用。

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

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

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

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

将当前 HEAD 重新设置基于你想要保留的最后一个提交。例如，如果你想重新排序最后 5 个提交，请使用

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

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

rebase 将在 pick 被替换为 edit 或列表中的某个步骤未能机械地解决冲突并需要你的帮助时停止。当你完成编辑和/或解决冲突后，你可以使用 git rebase --continue 继续。如果你认为事情变得过于复杂，你始终可以使用 git rebase --abort 放弃。即使在 rebase 完成后，你仍然可以通过使用 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 在子模块包含新文件或修改文件时会将子模块显示为已修改，以防止意外提交此类状态。当生成补丁输出或与 --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 可以帮助您执行三方合并，这可以通过重复合并过程多次来用于多方合并。通常情况下，您只执行一次三方合并（协调两条历史记录）并提交结果，但如果您愿意，您可以一次合并多个分支。

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

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

这会打印出两个分支共同基于的提交的名称。现在你应该查找这些提交的树对象，你可以很容易地使用以下命令做到这一点：

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

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

要执行合并，请执行以下操作：

这将直接在索引文件中为你完成所有简单的合并操作，你可以使用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路合并程序（例如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”一词来描述我们现在称为commit的内容。

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

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

在早期，Git（遵循UNIX的传统）是一堆非常简单的程序，你可以在脚本中使用它们，将一个程序的输出管道到另一个程序。这对于初始开发来说证明是好的，因为测试新事物更容易。但是，最近许多这些部分已成为内置函数，并且一些核心已被“库化”，即出于性能、可移植性原因以及避免代码重复而放入libgit.a中。

现在，你知道索引是什么（并在read-cache-ll.h中找到相应的data structure），并且只有几种对象类型（blob、tree、commit和tag）继承了它们来自struct object的公共结构，这是它们的第一个成员（因此，你可以将例如(struct object *)commit转换为与&commit->object相同的效果，即获取对象名称和标志）。

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

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

这仅仅是为了让你进入Git最“库化”的部分：修订版walker。

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

这意味着什么？

git rev-list是修订版walker的原始版本，它始终将修订版列表打印到stdout。它仍然有效，并且需要有效，因为大多数新的Git命令都以使用git rev-list的脚本开始。

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

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

git rev-parse的原始工作现在由setup_revisions()函数完成，该函数解析修订版和修订版walker的常用命令行选项。此信息存储在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/[email protected]/ https://lore.kernel.org/git/[email protected]/