gittutorial - Git 的教程简介

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

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

首先，请注意，您可以使用以下命令获取诸如 git log --graph 之类命令的文档：

或

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

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

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

Git 将回复

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

接下来，告诉 Git 对当前目录下所有文件的 contents 进行快照（注意 .），使用 git add

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

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

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

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

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

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

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

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

这将自动注意到任何修改（但不是新的）文件，将其添加到索引中并提交，所有这些都一步完成。

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

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

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

如果您还想在每个步骤中查看完整的差异，请使用：

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

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

如果您现在运行

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

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

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

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

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

此时，这两个分支已分叉，每个分支都进行了不同的更改。要将 experimental 中所做的更改合并到 master 中，请运行：

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

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

将提交合并的结果。最后，

将显示生成的 history 的精美图形表示。

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

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

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

分支既便宜又简单，因此这是一种尝试某些事物的不错方法。

假设 Alice 已在 /home/alice/project 中使用 Git 存储库启动了一个新项目，并且 Bob（他的 home 目录在同一台机器上）想要做出贡献。

Bob 从以下操作开始：

这将在 myrepo 中创建一个新目录，其中包含 Alice 存储库的克隆。该克隆与原始项目处于同等地位，拥有原始项目 history 的副本。

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

准备就绪后，他告诉 Alice 从 /home/bob/myrepo 中的存储库提取更改。她使用以下命令执行此操作：

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

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

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

Alice 可以使用 fetch 命令在不先合并的情况下查看 Bob 所做的工作；这允许 Alice 检查 Bob 所做的工作，使用一个特殊的符号 FETCH_HEAD，以确定他是否有任何值得提取的东西，如下所示：

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

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

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

Alice 可能希望查看他们两人自分叉以来所做的工作。她可以使用三点形式而不是两点形式

这意味着“显示任何一个可访问的所有内容，但排除两个都可访问的任何内容”。

请注意，这些范围表示法可用于 gitk 和 git log。

在检查了 Bob 所做的工作后，如果没有紧急情况，Alice 可能会决定继续工作而不从 Bob 那里提取。如果 Bob 的 history 确实有一些 Alice 立即需要的内容，Alice 可能会选择先将她的工作进度暂存，执行 pull，然后最终在生成的 history 之上取消暂存她的工作进度。

当您在一个小型紧密联系的小组中工作时，反复与同一个存储库交互的情况并不少见。通过定义远程存储库简写，您可以使其更容易

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

与长格式不同，当 Alice 使用 git remote 设置的远程存储库简写从 Bob 处提取时，提取的内容将存储在远程跟踪分支中，在本例中为 bob/master。所以在这之后

显示了 Bob 从 Alice 的 master 分支创建分支后所做的所有更改的列表。

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

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

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

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

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

（使用 git config -l 可以查看 git clone 创建的完整配置，并且 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 在可视化其历史记录方面做得更好。例如：

允许您浏览过去两周内修改了 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] 套件的一部分