gitcore-tutorial - 面向开发者的 Git 核心教程

git *

本教程讲解如何使用“核心”Git 命令来设置和操作 Git 仓库。

如果你只需要将 Git 用作版本控制系统，你可能更倾向于从“Git 教程入门”(gittutorial[7]) 或 Git 用户手册开始。

然而，如果你想了解 Git 的内部原理，理解这些底层工具将会很有帮助。

核心 Git 常被称为“管道”(plumbing)，而构建在其之上的更美观的用户界面则被称为“瓷器”(porcelain)。你可能并不经常需要直接使用管道，但当瓷器无法正常工作时，了解管道的运作方式会很有益处。

在编写本文档时，许多瓷器命令还是 Shell 脚本。为了简洁起见，本文仍然使用这些脚本作为示例，说明管道是如何组合在一起形成瓷器命令的。源码树包含了一些此类脚本在 contrib/examples/ 中供参考。尽管现在它们不再以 Shell 脚本实现，但关于管道层命令功能的描述依然有效。

创建一个新的 Git 仓库非常简单：所有 Git 仓库最初都是空的，你唯一需要做的就是找到一个你想用作工作树的子目录——可以是一个用于全新项目的空目录，或者是一个你想导入 Git 的现有工作树。

在我们的第一个示例中，我们将从零开始创建一个全新的仓库，没有预先存在的文件，我们将其命名为 git-tutorial。首先，创建一个子目录，进入该子目录，并使用 git init 初始化 Git 基础设施：

Git 将会回复：

这只是 Git 在告诉你，你没有进行任何奇怪的操作，它已经为你的新项目创建了一个本地 .git 目录结构。你现在会拥有一个 .git 目录，你可以用 ls 查看它。对于你的新空项目，它应该会显示三项内容，以及其他一些东西：

特别是，refs 子目录将包含另外两个子目录，分别命名为 heads 和 tags。它们的功能正如其名：它们包含对任意数量的不同开发头指针（又称分支）的引用，以及你为标记仓库中特定版本而创建的任何标签。

一点说明：特殊的 master 头指针是默认分支，这就是为什么创建 .git/HEAD 文件时即指向它，即使它目前还不存在。基本上，HEAD 链接始终指向你当前正在工作的分支，而你总是从期望在 master 分支上工作开始。

然而，这仅仅是一个惯例，你可以随意命名你的分支，甚至完全不需要拥有 master 分支。不过，许多 Git 工具会假定 .git/HEAD 是有效的。

你现在已经创建了第一个 Git 仓库。当然，由于它是空的，这并没有什么用，所以让我们开始用数据填充它。

我们将保持简单直接，先从填充几个琐碎的文件开始，以便感受一下流程。

首先，创建你想要在 Git 仓库中维护的任何随机文件。我们先从几个糟糕的例子开始，只是为了体会一下这是如何工作的：

你现在在工作树（又称工作目录）中创建了两个文件，但要真正登记你的劳动成果，你需要经过两个步骤：

第一步很简单：当你想要通知 Git 工作树的任何更改时，可以使用 git update-index 程序。该程序通常只是接受一个你想更新的文件名列表，但为了避免琐碎的错误，除非你明确使用 --add 标志告诉它你正在添加一个新条目（或使用 --remove 标志删除一个条目），否则它拒绝向索引添加新条目（或删除现有条目）。

因此，要用你刚刚创建的两个文件填充索引，你可以执行：

现在你已经告诉 Git 跟踪这两个文件了。

事实上，当你执行此操作时，如果你查看对象目录，会发现 Git 已经向对象数据库添加了两个新对象。如果你完全按照上述步骤操作，现在应该能够执行：

并看到两个文件：

它们分别对应于名称为 557db... 和 f24c7... 的对象。

如果你愿意，可以使用 git cat-file 查看这些对象，但你必须使用对象名称，而不是对象的文件名：

其中 -t 告诉 git cat-file 告知你对象的“类型”。Git 会告诉你，你拥有一个“blob”对象（即普通文件），你可以用以下命令查看其内容：

这将打印出 "Hello World"。对象 557db03 不过就是你 hello 文件内容而已。

总之，正如我们之前提到的，你通常永远不会去查看对象本身，而且输入 40 字符长的十六进制名称也不是你通常想要做的事情。上述题外话只是为了说明 git update-index 确实做了一些神奇的事情，实际上将你的文件内容保存到了 Git 对象数据库中。

更新索引还做了另一件事：它创建了一个 .git/index 文件。这就是描述你当前工作树的索引，你应该非常清楚这一点。同样，你通常不需要关心索引文件本身，但你应该意识到，你实际上还没有真正将文件“签入”到 Git 中，你只是通知了 Git 关于它们的存在。

然而，既然 Git 已经知道了它们，你现在可以开始使用一些最基本的 Git 命令来操作文件或查看它们的状态。

特别是，我们暂时不要将这两个文件签入 Git，我们先通过向 hello 添加一行来开始：

既然你已经告知 Git 关于 hello 的先前状态，现在你可以使用 git diff-files 命令询问 Git，与旧索引相比，树中发生了什么变化：

糟糕。这不太容易阅读。它只是输出了其内部版本的 diff，但这个内部版本实际上只是告诉你，它注意到 "hello" 已经被修改，并且它拥有的旧对象内容已被其他东西替换。

为了使其可读，我们可以使用 -p 标志告诉 git diff-files 将差异输出为补丁：

即我们通过向 hello 添加另一行所引起的更改的差异。

换句话说，git diff-files 总是向我们展示记录在索引中的内容与工作树中当前内容之间的差异。这非常有用。

git diff-files -p 的常用简写是直接写 git diff，它会执行相同的操作。

现在，我们要进入 Git 的下一个阶段，即将 Git 在索引中知道的文件提交为一棵真正的树。我们分两个阶段进行：创建一个树对象，并将该树对象与关于树的说明以及我们如何达到该状态的信息一起作为提交对象提交。

创建树对象很简单，使用 git write-tree 完成。没有选项或其他输入：git write-tree 将获取当前的索引状态，并写入一个描述整个索引的对象。换句话说，我们现在将所有不同的文件名及其内容（和权限）绑定在一起，并创建了 Git “目录”对象的等价物：

这只会输出结果树的名称，在这种情况下（如果你完全按照我描述的操作），它应该是：

这是另一个难以理解的对象名称。同样，如果你愿意，可以使用 git cat-file -t 8988d... 查看这次的对象不是“blob”对象，而是“树”对象（你也可以使用 git cat-file 实际输出原始对象内容，但你会看到主要是二进制乱码，所以这不太有趣）。

然而，通常你永远不会单独使用 git write-tree，因为通常你总是使用 git commit-tree 命令将一棵树提交为提交对象。事实上，不单独使用 git write-tree 而是直接将其结果作为参数传递给 git commit-tree 会更容易。

git commit-tree 通常需要几个参数——它想知道提交的父级是什么，但由于这是此新仓库中的第一次提交，它没有父级，我们只需要传入树的对象名称。然而，git commit-tree 还想在标准输入上获取提交信息，并将生成的提交对象名称写入其标准输出。

这就是我们创建 .git/refs/heads/master 文件的地方，它由 HEAD 指向。该文件应该包含对 master 分支树顶部的引用，既然这正是 git commit-tree 输出的内容，我们可以通过一系列简单的 Shell 命令来完成所有操作：

在这种情况下，这创建了一个与任何其他事物无关的全新提交。通常你为一个项目只做一次，所有以后的提交都将以较早的提交为父级。

同样，通常你永远不会手动执行此操作。有一个名为 git commit 的有用脚本会为你完成所有这些工作。所以你本来可以只写 git commit，它就会为你完成上面的魔法脚本操作。

还记得我们是如何对 hello 文件执行 git update-index，然后更改 hello，并能够将 hello 的新状态与索引文件中保存的状态进行比较的吗？

进一步说，还记得我说过 git write-tree 将索引文件的内容写入树，因此我们刚刚提交的实际上是 hello 文件的原始内容，而不是新的内容吗？我们这样做是有意为之，为了展示索引状态与工作树状态之间的区别，以及即使在我们提交内容时，它们也不必匹配。

和以前一样，如果我们在 git-tutorial 项目中执行 git diff-files -p，我们仍然会看到上次看到的相同差异：索引文件并没有因为提交任何内容而改变。然而，现在我们已经提交了一些东西，我们可以学习使用一个新命令：git diff-index。

与显示索引文件和工作树之间差异的 git diff-files 不同，git diff-index 显示已提交的树与索引文件或工作树之间的差异。换句话说，git diff-index 需要一棵要进行对比的树，而在我们进行提交之前，我们无法做到这一点，因为我们没有任何可以对比的树。

但现在我们可以这样做：

（其中 -p 具有与在 git diff-files 中相同的含义），它将向我们展示相同的差异，但原因完全不同。现在我们不是将工作树与索引文件进行比较，而是与我们刚刚写入的树进行比较。碰巧这两者显然是相同的，所以我们得到了相同的结果。

同样，因为这是一个常见操作，你也可以通过以下简写完成：

它最终会为你执行上述操作。

换句话说，git diff-index 通常将树与工作树进行比较，但在给出 --cached 标志时，它被告知只与索引缓存内容进行比较，完全忽略当前工作树状态。由于我们刚刚将索引文件写入 HEAD，因此执行 git diff-index --cached -p HEAD 应该返回一组空差异，这正是它所做的。

然而，我们的下一步是提交我们所做的更改，同样，要了解正在发生的事情，请记住“工作树内容”、“索引文件”和“已提交树”之间的区别。我们的工作树中有想要提交的更改，并且我们必须始终通过索引文件进行工作，因此我们需要做的第一件事是更新索引缓存：

（注意这次我们不需要 --add 标志，因为 Git 已经知道了该文件）。

注意这里不同的 git diff-* 版本发生了什么。在我们更新索引中的 hello 后，git diff-files -p 现在显示没有差异，但 git diff-index -p HEAD 仍然确实显示当前状态与我们提交的状态不同。事实上，现在无论我们是否使用 --cached 标志，git diff-index 都显示相同的差异，因为现在索引与工作树是一致的。

现在，既然我们已经在索引中更新了 hello，我们可以提交新版本。我们可以再次手动写入树并提交该树（这次我们必须使用 -p HEAD 标志告诉提交，HEAD 是新提交的父级，并且这不是初始提交），但你已经做过一次了，所以这次让我们使用有用的脚本：

它会为你启动一个编辑器来编写提交信息，并告诉你一些你所做的事情。

写下任何你想要的信息，所有以 # 开头的行都将被修剪掉，其余部分将用作更改的提交信息。如果你决定在这一点上最终不想提交任何内容（你可以继续编辑内容并更新索引），你可以只留下一个空信息。否则，git commit 将为你提交更改。

你现在已经进行了第一次真正的 Git 提交。如果你有兴趣了解 git commit 到底做了什么，请随意研究：它是一些非常简单的 Shell 脚本，用于生成有用的（？）提交信息头，以及一些实际执行提交本身的单行程序（git commit）。

虽然创建更改很有用，但如果你能稍后判断出发生了什么变化，那就更有用了。最实用的命令是 diff 系列的另一个命令，即 git diff-tree。

git diff-tree 可以被赋予两棵任意的树，它会告诉你它们之间的差异。不过，也许更常见的是，你可以只给它一个单独的提交对象，它会自己计算出该提交的父级，并直接显示差异。因此，为了获得我们已经见过几次的相同差异，我们现在可以执行：

（同样，-p 表示以人类可读的补丁形式显示差异），它将显示最后一次提交（在 HEAD 中）实际改变了什么。

更有趣的是，你还可以给 git diff-tree 加上 --pretty 标志，这会告诉它同时显示提交信息以及提交的作者和日期，并且你可以告诉它显示一系列的差异。或者，你可以告诉它保持“静默”，根本不显示差异，只显示实际的提交信息。

事实上，与 git rev-list 程序（生成修订列表）结合使用，git diff-tree 最终成为了一个真正的更改源泉。你可以使用一个简单的脚本通过将 git rev-list 的输出传送到 git diff-tree --stdin 来模拟 git log、git log -p 等，这正是早期版本的 git log 的实现方式。

在 Git 中，有两种标签：“轻量级”标签和“注释标签”。

“轻量级”标签从技术上讲不过是一个分支，只是我们将其放在 .git/refs/tags/ 子目录中，而不是称其为 head。因此，最简单的标签形式仅涉及：

它只是将当前的 HEAD 写入 .git/refs/tags/my-first-tag 文件，之后你就可以为该特定状态使用此符号名称。例如，你可以执行：

将你当前的状态与该标签进行比较，此时这显然是一个空的差异，但如果你继续开发和提交东西，你可以使用你的标签作为“锚点”来查看自你标记以来发生了什么变化。

“注释标签”实际上是一个真正的 Git 对象，不仅包含指向你想要标记的状态的指针，还包含一个小的标签名称和信息，以及可选的 PGP 签名，声明确实是你进行了该标签。你可以使用 -a 或 -s 标志通过 git tag 创建这些注释标签：

它将对当前的 HEAD 进行签名（但你也可以给它另一个参数来指定要标记的内容，例如，你可以使用 git tag <tagname> mybranch 标记当前的 mybranch 点）。

你通常只为主要版本之类的内容进行签名标签，而轻量级标签适用于你想要做的任何标记——任何时候当你决定想要记住某个点时，只需为此创建一个私有标签，你就拥有了该点状态的漂亮符号名称。

Git 仓库通常是完全自给自足且可重定位的。例如，与 CVS 不同，没有“仓库”和“工作树”的单独概念。Git 仓库通常就是工作树，本地 Git 信息隐藏在 .git 子目录中。没有其他东西。所见即所得。

这有两个含义：

注意，第二点即使跨机器也适用。你可以通过任何常规复制机制复制远程 Git 仓库，无论是 scp、rsync 还是 wget。

复制远程仓库时，你至少需要在执行此操作时更新索引缓存，特别是对于别人的仓库，你通常希望确保索引缓存处于某种已知状态（你不知道他们做了什么但还没签入），所以通常你会用以下命令预置 git update-index：

这将强制根据 HEAD 指向的树完全重建索引。它将索引内容重置为 HEAD，然后 git update-index 确保将所有索引条目与签出的文件匹配。如果原始仓库在其工作树中有未提交的更改，git update-index --refresh 会注意到并告诉你它们需要更新。

上述操作也可以简单地写为：

事实上，许多常见的 Git 命令组合可以用 git xyz 接口进行脚本化。你可以通过观察各种 git 脚本所做的事情来学习。例如，git reset 曾经是 git reset 中实现的上述两行，但像 git status 和 git commit 之类的事情是围绕基本 Git 命令编写的稍复杂的脚本。

许多（大多数？）公共远程仓库不会包含任何签出的文件，甚至不会包含索引文件，而只包含实际的核心 Git 文件。这样的仓库通常甚至没有 .git 子目录，而是直接将所有 Git 文件放在仓库中。

要为这样的“原始”Git 仓库创建你自己的本地实时副本，你需要首先为项目创建自己的子目录，然后将原始仓库内容复制到 .git 目录中。例如，要创建你自己的 Git 仓库副本，你需要执行以下操作：

随后是

以填充索引。然而，现在你已经填充了索引，并拥有了所有 Git 内部文件，但你会注意到你实际上没有任何可供操作的工作树文件。要获取这些文件，你需要使用以下命令签出它们：

其中 -u 标志意味着你希望签出保持索引更新（这样你之后就不必刷新它），-a 标志意味着“签出所有文件”（如果你有陈旧的副本或已签出树的旧版本，你可能还需要先添加 -f 标志，告诉 git checkout-index 强制覆盖任何旧文件）。

同样，这一切都可以简化为：

它最终会为你完成所有上述工作。

你现在已经成功复制了别人的（我的）远程仓库，并将其签出。

Git 中的分支实际上不过是指向 .git/refs/ 子目录内 Git 对象数据库的指针，正如我们已经讨论过的，HEAD 分支不过是指向这些对象指针之一的符号链接。

你可以随时通过在项目历史记录中选择任意一点，并将该对象的 SHA-1 名称写入 .git/refs/heads/ 下的文件中来创建新分支。你可以使用任何你想要的文件名（事实上，子目录也可以），但惯例是“正常”分支称为 master。不过这只是惯例，没有任何强制规定。

为了举例说明，让我们回到我们之前使用的 git-tutorial 仓库，并在其中创建一个分支。你可以通过简单地说你想签出一个新分支来完成：

将基于当前的 HEAD 位置创建一个新分支，并切换到该分支。

你可以随时通过以下操作跳回你原始的 master 分支：

（或者任何其他分支名称），如果你忘记了自己当前在哪个分支上，一个简单的：

会告诉你它指向哪里。要获取你拥有的分支列表，你可以说：

它曾经不过是围绕 ls .git/refs/heads 的一个简单脚本。你当前所在的分支前面会有一个星号。

有时你可能希望创建一个新分支而不实际签出并切换到它。如果是这样，只需使用命令：

它只会创建该分支，但不会做任何进一步的操作。之后——一旦你决定真的要在该分支上开发——你就可以使用带分支名参数的常规 git switch 切换到该分支。

拥有分支的想法之一是你在其中进行一些（可能是实验性的）工作，并最终将其合并回主分支。因此，假设你创建了上述与原始 master 分支相同的 mybranch，让我们确保我们在该分支中，并在那里做一些工作。

在这里，我们只是向 hello 添加了另一行，并且我们使用了一种简写，通过直接给 git commit 提供文件名，并加上 -i 标志（它告诉 Git 在制作提交时包含该文件以及你到目前为止对索引文件所做的任何更改），从而同时执行 git update-index hello 和 git commit。-m 标志用于从命令行提供提交日志信息。

现在，为了让它更有趣一点，让我们假设别人在原始分支中做了一些工作，并通过回到 master 分支并以不同方式编辑同一个文件来模拟这一点：

这里，花点时间查看 hello 的内容，并注意它们是如何不包含我们在 mybranch 中所做的工作的——因为那项工作根本没有在 master 分支中发生。然后执行：

因为 master 分支显然心情更好。

现在，你有两个分支，你决定要合并已完成的工作。在我们做之前，让我们引入一个很酷的图形化工具，帮助你查看正在发生的事情：

将以图形方式向你显示你的两个分支（这就是 --all 的含义：通常它只会显示你当前的 HEAD）及其历史记录。你还可以准确地看到它们是如何从一个共同来源产生的。

总之，让我们退出 gitk（^Q 或文件菜单），并决定我们要将我们在 mybranch 分支上所做的工作合并到 master 分支（目前也是我们的 HEAD）中。为此，有一个名为 git merge 的好脚本，它想知道你想解决哪些分支以及合并的内容：

其中第一个参数将被用作自动合并可以解决情况下的提交信息。

现在，在这种情况下，我们故意造成了一种需要手动修复合并的情况，所以 Git 会尽可能自动完成它（在这种情况下，只是合并了 example 文件，在 mybranch 分支中没有差异），并说：

它告诉你它进行了“自动合并”，但由于 hello 中的冲突而失败了。

别担心。它以你如果用过 CVS 应该非常熟悉的相同形式将（琐碎的）冲突留在了 hello 中，所以让我们在我们的编辑器（无论是什么）中打开 hello，并以某种方式修复它。我建议只需将其设置为 hello 包含所有四行：

一旦你对你的手动合并感到满意，只需执行：

它会大声警告你，你现在正在提交一个合并（这是正确的，所以不用管它），你可以写一个关于你在 git merge 世界中的冒险的小合并信息。

完成后，启动 gitk --all 以图形方式查看历史记录的样子。注意 mybranch 仍然存在，你可以切换到它，并根据需要继续使用它。mybranch 分支将不包含合并，但下次你从 master 分支合并它时，Git 将知道你是如何合并它的，所以你不必再次进行那次合并。

另一个有用的工具，特别是如果你并不总是在 X-Window 环境中工作时，是 git show-branch。

前两行表示它正在显示两个分支及其树顶提交的标题，你当前在 master 分支（注意星号 * 字符），后续输出行的第一列用于显示 master 分支中包含的提交，第二列用于 mybranch 分支。显示了三个提交及其标题。它们都在第一列中有非空白字符（* 显示当前分支上的普通提交，- 是合并提交），这意味着它们现在是 master 分支的一部分。只有“Some work”提交在第二列中有加号 + 字符，因为 mybranch 尚未合并以包含来自 master 分支的这些提交。提交日志信息括号内的字符串是一个短名称，你可以用来命名该提交。在上面的例子中，master 和 mybranch 是分支头指针。master^ 是 master 分支头指针的第一个父级。如果你想查看更复杂的情况，请参阅 gitrevisions[7]。

现在，让我们假装你是那个在 mybranch 中完成了所有工作的人，你的辛勤工作成果终于被合并到了 master 分支。让我们回到 mybranch，并运行 git merge 以将“上游更改”带回你的分支。

这输出类似以下内容（实际的提交对象名称会有所不同）：

因为你的分支不包含比已经合并到 master 分支中更多的内容，所以合并操作实际上并没有进行合并。相反，它只是将你分支的树顶部更新为 master 分支的树顶部。这通常被称为快进 (fast-forward) 合并。

你可以再次运行 gitk --all 来查看提交祖先的样子，或者运行 show-branch，它会告诉你这一点。

通常你与别人合并比与你自己的分支合并更常见，所以值得指出的是 Git 让这也很容易，事实上，它与进行 git merge 并没有太大不同。事实上，远程合并最终不过是“将工作从远程仓库获取到临时标签中”，然后进行 git merge。

从远程仓库获取是通过 git fetch 完成的，这并不奇怪：

可以使用以下传输方式之一来命名要从中下载的仓库：

一旦你从远程仓库获取，你就将该内容与你的当前分支进行 合并。

然而，获取然后立即合并是如此常见，以至于被称为 git pull，你只需执行：

并可选择提供远程端的分支名称作为第二个参数。

你很可能会不时地从同一个远程仓库进行拉取。作为简写，你可以将远程仓库 URL 存储在本地仓库的配置文件中，如下所示：

然后在使用 git pull 时使用 "linus" 关键字代替完整的 URL。

示例：

以上等同于：

我们说过本教程展示了管道如何帮助你处理无法正常工作的瓷器，但到目前为止我们还没有谈论合并真正是如何工作的。如果你是第一次学习本教程，我建议跳过此部分直接阅读“发布你的工作”章节，稍后再回过头来。

OK，还在看吗？为了给我们一个示例看看，让我们回到早期的包含 "hello" 和 "example" 文件的仓库，并将我们自己带回合并前的状态：

记住，在运行 git merge 之前，我们的 master 头指针处于 "Some fun." 提交，而我们的 mybranch 头指针处于 "Some work." 提交。

回退后，提交结构应该如下所示：

现在我们可以准备通过手动方式试验合并。

git merge 命令在合并两个分支时使用 3 向合并算法。首先，它找到它们之间的共同祖先。它使用的命令是 git merge-base：

该命令将共同祖先的提交对象名称写入标准输出，所以我们将它的输出捕获到一个变量中，因为我们将在下一步中使用它。顺便说一句，在这种情况下，共同祖先提交是 "Initial commit" 提交。你可以通过以下方式分辨：

在找到共同祖先提交后，第二步如下：

这是我们已经见过的同一个 git read-tree 命令，但它接受三棵树，与之前的示例不同。这将每棵树的内容读入索引文件中的不同阶段（第一棵树进入阶段 1，第二棵进入阶段 2，依此类推）。将三棵树读入三个阶段后，在所有三个阶段中都相同的路径被折叠到阶段 0。此外，在三个阶段中的两个阶段中相同的路径被折叠到阶段 0，取来自阶段 2 或阶段 3（无论哪一个与阶段 1 不同）的 SHA-1（即只有一侧相对于共同祖先发生了更改）。

在折叠操作之后，在三棵树中不同的路径保留在非零阶段。此时，你可以用以下命令检查索引文件：

在我们只有两个文件的示例中，我们没有未更改的文件，因此只有 example 导致了折叠。但在现实中的大型项目中，当一个提交中只有少量文件发生更改时，这种折叠往往会很快地琐碎合并大部分路径，仅在非零阶段留下少数真正的更改。

要仅查看非零阶段，请使用 --unmerged 标志：

合并的下一步是使用 3 向合并来合并文件的这三个版本。这是通过将 git merge-one-file 命令作为参数之一传递给 git merge-index 命令来完成的：

git merge-one-file 脚本被调用时带有描述那三个版本的参数，并负责将合并结果留在工作树中。这是一个相当直接的 Shell 脚本，最终调用 RCS 套件中的 merge 程序来执行文件级的 3 向合并。在这种情况下，merge 检测到了冲突，带有冲突标记的合并结果被留在工作树中……如果你此时再次运行 ls-files --stage，可以看到这一点：

这是 git merge 将控制权交还给你后索引文件和工作文件的状态，留下了冲突的合并供你解决。注意路径 hello 仍未合并，此时你用 git diff 看到的是自阶段 2（即你的版本）以来的差异。

所以，我们可以使用远程仓库中别人的工作，但你怎么才能准备好一个仓库让别人从中拉取呢？

你在工作树中进行真正的实际工作，其主仓库挂在其 .git 子目录下。你可以使该仓库远程可访问，并要求人们从中拉取，但实际上这通常不是通常的做法。推荐的方式是拥有一个公共仓库，使其可被其他人访问，当你在主工作树中所做的更改状态良好时，从它更新公共仓库。这通常被称为推送 (pushing)。

将更改从你的本地（私有）仓库发布到你的远程（公共）仓库需要远程机器上的写权限。你需要在那里拥有一个 SSH 帐户才能运行单个命令，git-receive-pack。

首先，你需要在远程机器上创建一个空仓库，它将存放你的公共仓库。这个空仓库将在之后通过向其推送内容来填充并保持更新。显然，此仓库创建只需要执行一次。

你私有仓库的 Git 目录通常是 .git，但你的公共仓库通常以项目名称命名，即 <project>.git。让我们为项目 my-git 创建这样一个公共仓库。登录远程机器后，创建一个空目录：

然后，通过运行 git init 将该目录变为 Git 仓库，但这次，因为它的名称不是通常的 .git，所以我们稍微不同地操作：

确保此目录可供你想要通过你选择的传输方式拉取更改的其他人访问。你还需要确保你在 $PATH 上有 git-receive-pack 程序。

你的“公共仓库”现在准备好接受你的更改了。回到你拥有私有仓库的机器上。从那里，运行此命令：

这会将你的公共仓库同步，以匹配命名分支头指针（即这种情况下的 master）以及你当前仓库中可从它们到达的对象。

作为一个真实示例，这就是我更新我公共 Git 仓库的方式。Kernel.org 镜像网络负责传播到其他公开可见的机器：

早些时候，我们看到 .git/objects/??/ 目录下的一个文件存储为你创建的每个 Git 对象。这种表示法对于原子且安全地创建非常有效，但对于通过网络传输却不太方便。由于 Git 对象一旦创建就不可变，因此有一种通过“将它们打包在一起”来优化存储的方法。命令：

会为你完成。如果你按照教程示例操作，到目前为止你应该已经在 .git/objects/??/ 目录中积累了大约 17 个对象。git repack 会告诉你它打包了多少个对象，并将打包文件存储在 .git/objects/pack 目录中。

如果你是一个偏执狂，运行 git verify-pack 命令会检测你是否有损坏的包，但不要太担心。我们的程序永远是完美的 ;-)。

一旦你打包了对象，你就不再需要保留包文件中包含的未打包对象了。

会为你移除它们。

如果你好奇的话，可以在运行 git prune-packed 之前和之后尝试运行 find .git/objects -type f。此外，git count-objects 会告诉你仓库中有多少个未打包的对象以及它们消耗了多少空间。

如果你此时再次运行 git repack，它会显示 "Nothing new to pack."。一旦你继续开发并积累了更改，再次运行 git repack 将创建一个新的包，其中包含自你上次打包仓库以来创建的对象。我们建议你在初始导入后不久就打包你的项目（除非你是从零开始你的项目），然后根据项目的活跃程度，偶尔运行一次 git repack。

当仓库通过 git push 和 git pull 同步时，源仓库中打包的对象通常会以未打包的状态存储在目标仓库中。虽然这允许你在两端使用不同的打包策略，但也意味着你可能需要偶尔重新打包两个仓库。

虽然 Git 是一个真正分布式的系统，但通常方便以非正式的开发者层次结构来组织你的项目。Linux 内核开发就是这样运行的。在 Randy Dunlap 的演示文稿（第 17 页，“Merges to Mainline”）中有很好的说明。

应该强调的是，这种层次结构纯粹是非正式的。Git 中没有任何基础性的东西强制执行这种层次结构所暗示的“补丁流链”。你不必只从一个远程仓库拉取。

推荐给“项目负责人”的工作流程如下：

推荐给在此项目上工作并拥有自己的“公共仓库”的“子系统维护者”的工作周期如下：

推荐给没有“公共”仓库的“个人开发者”的工作周期有些不同。它如下：

如果你来自 CVS 背景，前一节中建议的协作风格对你来说可能是全新的。你不必担心。Git 也支持你可能更熟悉的“共享公共仓库”风格的协作。

有关详情，请参阅 gitcvs-migration[7]。

您很可能会同时处理多项事务。使用 Git 的分支功能，可以轻松管理这些相对独立的任务。

我们之前已经了解过分支的工作原理，即使用“fun”和“work”两个分支的示例。如果有两个以上的分支，思路也是一样的。假设您从“master”分支的头部开始，在“master”分支中有一些新代码，同时在“commit-fix”和“diff-fix”分支中有两个独立的修复。

这两个修复都经过了充分测试，此时您希望将它们合并进来。您可以先合并 diff-fix，然后再合并 commit-fix，如下所示：

结果如下：

然而，当您拥有的是一组完全独立的变更时（如果顺序很重要，那么根据定义它们就不是独立的），没有特别的理由必须先合并其中一个分支，再合并另一个。您可以选择一次性将这两个分支合并到当前分支中。首先，让我们撤销刚才的操作并重新开始。我们希望在执行那两次合并之前回到 master 分支的状态，方法是将它重置到 master~2：

您可以确保 git show-branch 的结果与刚才那两次 git merge 之前状态一致。然后，与其连续运行两次 git merge 命令，不如将这两个分支的头部一次性合并（这被称为制作章鱼式合并 (Octopus)）：

请注意，不要仅仅因为可以这样做就进行章鱼式合并。章鱼式合并是合法的操作，如果您同时合并超过两个独立的变更，它通常能让提交历史更易于查看。但是，如果您在合并的任何分支中遇到合并冲突，并且需要手动解决，这说明这些分支中的开发工作并非真正独立。在这种情况下，您应该一次合并一个，记录下您是如何解决冲突的，以及为什么您倾向于保留其中一侧的变更。否则，这只会让项目历史变得更难追踪，而不是更易于理解。

gittutorial[7], gittutorial-2[7], gitcvs-migration[7], git-help[1], giteveryday[7], Git 用户手册

Git[1] 套件的一部分