gittutorial - Git 入门教程

本教程解释了如何将新项目导入 Git、对其进行更改以及与其他开发人员共享更改。

如果您主要对使用 Git 获取项目（例如，测试最新版本）感兴趣，您可能更喜欢从Git 用户手册的前两章开始。

首先，请注意，您可以通过以下方式获取诸如 git log --graph 等命令的文档：

或

通过后者，您可以使用您选择的手册查看器；更多信息请参阅 git-help[1]。

在执行任何操作之前，最好使用您的姓名和公开电子邮件地址向 Git 介绍自己。最简单的方法是：

假设您有一个包含您初始工作的 tarball project.tar.gz。您可以将其置于 Git 版本控制之下，如下所示。

Git 将回复

您现在已经初始化了工作目录——您可能会注意到一个名为 .git 的新目录已创建。

接下来，告诉 Git 拍摄当前目录下所有文件内容快照（注意 .），使用 git add

此快照现已存储在 Git 称为“索引”的临时暂存区中。您可以使用 git commit 将索引内容永久存储到仓库中

这将提示您输入提交消息。您现在已将项目的第一个版本存储在 Git 中。

修改一些文件，然后将其更新后的内容添加到索引中

您现在可以提交了。您可以使用带有 --cached 选项的 git diff 查看即将提交的内容

（如果没有 --cached，git diff 将显示您已进行但尚未添加到索引中的任何更改。）您还可以使用 git status 获取当前情况的简要摘要

如果您需要进行任何进一步的调整，请立即进行，然后将任何新修改的内容添加到索引中。最后，使用以下命令提交您的更改：

这将再次提示您输入描述更改的消息，然后记录项目的新版本。

或者，您可以使用以下命令，而不是预先运行 git add：

这将自动识别任何已修改（但不是新增）的文件，将它们添加到索引中，然后一次性提交。

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

许多版本控制系统提供一个 add 命令，告诉系统开始跟踪新文件的更改。Git 的 add 命令做的事情更简单、更强大：git add 既用于新文件，也用于新修改的文件，在这两种情况下，它都会拍摄给定文件的快照，并将内容暂存到索引中，准备包含在下一次提交中。

您可以在任何时候使用以下命令查看您的更改历史：

如果您还想查看每一步的完整差异，请使用：

通常，更改的概述有助于了解每个步骤

一个 Git 仓库可以维护多个开发分支。要创建一个名为 experimental 的新分支，请使用：

如果您现在运行

您将获得所有现有分支的列表

experimental 分支是您刚刚创建的分支，而 master 分支是为您自动创建的默认分支。星号标记您当前所在的分支；输入

切换到 experimental 分支。现在编辑一个文件，提交更改，然后切换回 master 分支

检查您所做的更改是否不再可见，因为它是在 experimental 分支上进行的，而您已切换回 master 分支。

您可以在 master 分支上进行不同的更改

此时两个分支已经分叉，各自进行了不同的更改。要将 experimental 中的更改合并到 master 中，请运行

如果更改没有冲突，则完成。如果存在冲突，则会在有问题的文件中留下标记，显示冲突；

将显示此内容。一旦您编辑文件以解决冲突，

将提交合并结果。最后，

将显示结果历史记录的漂亮图形表示。

此时，您可以使用以下命令删除 experimental 分支：

此命令确保 experimental 分支中的更改已在当前分支中。

如果您在一个分支 crazy-idea 上进行开发，然后后悔了，您始终可以使用以下命令删除该分支：

分支成本低廉且易于操作，因此这是尝试新事物的绝佳方式。

假设 Alice 在 /home/alice/project 中启动了一个带有 Git 仓库的新项目，而 Bob（他在同一台机器上有一个主目录）想要贡献。

Bob 首先使用

这会创建一个新目录 myrepo，其中包含 Alice 仓库的克隆。该克隆与原始项目地位相同，拥有原始项目历史记录的自己的副本。

Bob 随后进行一些更改并提交它们

准备就绪后，他告诉 Alice 从 /home/bob/myrepo 的仓库中拉取更改。她这样做：

这将 Bob 的 master 分支中的更改合并到 Alice 的当前分支中。如果 Alice 同时进行了自己的更改，则她可能需要手动解决任何冲突。

pull 命令因此执行两个操作：它从远程分支获取更改，然后将它们合并到当前分支中。

请注意，通常情况下，Alice 在发起此 pull 之前会希望她的本地更改已提交。如果 Bob 的工作与 Alice 自历史分叉以来所做的工作发生冲突，Alice 将使用她的工作树和索引来解决冲突，并且现有的本地更改将干扰冲突解决过程（Git 仍将执行 fetch 但会拒绝合并 — Alice 将不得不以某种方式处理掉她的本地更改并在发生这种情况时再次 pull）。

Alice 可以不先合并就查看 Bob 做了什么，使用 fetch 命令；这允许 Alice 使用特殊符号 FETCH_HEAD 检查 Bob 做了什么，以便确定他是否有任何值得拉取的内容，如下所示：

即使 Alice 有未提交的本地更改，此操作也是安全的。范围表示法 HEAD..FETCH_HEAD 意为“显示所有可从 FETCH_HEAD 到达的内容，但排除所有可从 HEAD 到达的内容”。Alice 已经知道所有导致她当前状态（HEAD）的内容，并使用此命令查看 Bob 在她尚未看到的状态（FETCH_HEAD）中有什么。

如果 Alice 想要可视化 Bob 自他们的历史分叉以来所做的工作，她可以发出以下命令：

这使用了我们之前在 git log 中看到的相同的双点范围表示法。

Alice 可能想查看自他们分叉以来两人都做了什么。她可以使用三点形式而不是双点形式：

这意味着“显示所有可从任一处到达的内容，但排除所有可从两者同时到达的内容”。

请注意，这些范围表示法可与 gitk 和 git log 一起使用。

在检查了 Bob 的工作之后，如果没有紧急情况，Alice 可能会决定继续工作而不再从 Bob 那里拉取。如果 Bob 的历史记录确实包含 Alice 急需的内容，Alice 可能会选择先暂存她的正在进行的工作，执行一次 pull，然后最终在结果历史记录之上恢复她正在进行的工作。

当您在一个紧密的小组中工作时，反复与同一个仓库交互并不罕见。通过定义远程仓库的简称，您可以使其变得更容易：

有了这个，Alice 可以单独执行 pull 操作的第一部分，使用 git fetch 命令，而无需将其与自己的分支合并，使用：

与长格式不同，当 Alice 使用通过 git remote 设置的远程仓库简称从 Bob 那里获取时，获取到的内容存储在一个远程跟踪分支中，本例中是 bob/master。因此在此之后：

显示了 Bob 自从从 Alice 的 master 分支分叉以来所做的所有更改的列表。

检查完这些更改后，Alice 可以将更改合并到她的 master 分支中：

此 merge 也可以通过从她自己的远程跟踪分支拉取来完成，如下所示：

请注意，git pull 始终合并到当前分支，无论命令行上提供了什么其他内容。

之后，Bob 可以使用以下命令用 Alice 的最新更改更新他的仓库：

请注意，他不需要提供 Alice 仓库的路径；当 Bob 克隆 Alice 的仓库时，Git 将她的仓库位置存储在仓库配置中，并且该位置用于拉取操作。

（通过 git clone 创建的完整配置可以使用 git config -l 查看，并且 git-config[1] 手册页解释了每个选项的含义。）

Git 还会在 origin/master 名称下保留 Alice 的 master 分支的原始副本。

如果 Bob 以后决定从不同的主机工作，他仍然可以使用 ssh 协议执行克隆和拉取操作：

或者，Git 有一个原生协议，或者可以使用 http；有关详细信息，请参阅 git-pull[1]。

Git 也可以以类似 CVS 的模式使用，即一个中央仓库，各种用户将更改推送到其中；请参阅 git-push[1] 和 gitcvs-migration[7]。

Git 历史记录表示为一系列相互关联的提交。我们已经看到 git log 命令可以列出这些提交。请注意，每个 git log 条目的第一行也给出了提交的名称：

我们可以将此名称提供给 git show 以查看此提交的详细信息。

但是有其他方式可以引用提交。您可以使用名称的任何初始部分，只要它足够长以唯一标识提交即可：

每个提交通常都有一个“父”提交，它指向项目的先前状态：

请注意，合并提交可以有多个父级：

您也可以给提交自定义名称；运行后：

您可以使用名称 v2.5 引用 1b2e1d63ff。如果您打算与其他人共享此名称（例如，用于标识发布版本），您应该创建一个“标签”对象，并可能对其进行签名；有关详细信息，请参阅 git-tag[1]。

任何需要知道提交的 Git 命令都可以接受这些名称中的任何一个。例如：

请谨慎使用最后一个命令：除了丢失工作目录中的任何更改之外，它还会从该分支中删除所有后续提交。如果此分支是唯一包含这些提交的分支，它们将丢失。此外，不要在其他开发人员从中拉取的公共可见分支上使用 git reset，因为它会强制其他开发人员进行不必要的合并来清理历史记录。如果您需要撤消已推送的更改，请改用 git revert。

git grep 命令可以在项目的任何版本中搜索字符串，因此：

在 v2.5 中搜索所有“hello”的出现。

如果您省略提交名称，git grep 将在您当前目录中管理的所有文件中搜索。所以：

是一种快速搜索 Git 跟踪的文件的方法。

许多 Git 命令也接受提交集，这些提交集可以通过多种方式指定。以下是 git log 的一些示例：

您还可以给 git log 提供一个提交的“范围”，其中第一个提交不一定是第二个提交的祖先；例如，如果分支 stable 和 master 的尖端在一段时间前从一个共同提交分叉，那么：

将列出在 master 分支中但不在 stable 分支中的提交，而：

将显示在 stable 分支中但不在 master 分支中的提交列表。

git log 命令有一个弱点：它必须以列表形式呈现提交。当历史记录中存在分歧然后合并回一起的开发线时，git log 呈现这些提交的顺序是无意义的。

大多数拥有多个贡献者的项目（例如 Linux 内核或 Git 本身）都有频繁的合并，而 gitk 在可视化其历史记录方面做得更好。例如：

允许您浏览最近 2 周内修改了 drivers 目录下文件的任何提交。（注意：您可以通过按住 control 键并按“-”或“+”来调整 gitk 的字体。）

最后，大多数接受文件名的命令都可以选择在任何文件名前加上一个提交，以指定文件的特定版本：

您还可以使用 git show 来查看任何此类文件：

本教程应该足以让您为项目执行基本的分布式版本控制。但是，要完全理解 Git 的深度和强大之处，您需要理解其所基于的两个简单概念：

本教程的第二部分解释了对象数据库、索引文件以及一些您需要充分利用 Git 的其他零碎知识。您可以在 gittutorial-2[7] 找到它。

如果您不想立即继续，此时可能还有一些其他有趣的插曲：

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

Git[1] 套件的一部分