简体中文 ▾ 主题 ▾ 最新版本 ▾ gittutorial 最后更新于 2.46.1

名称

gittutorial - Git 入门教程

概要

git *

描述

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

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

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

$ man git-log

或

$ git help log

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

在进行任何操作之前，最好先向 Git 介绍一下自己，包括您的姓名和公开电子邮件地址。最简单的方法是

$ git config --global user.name "Your Name Comes Here"
$ git config --global user.email you@yourdomain.example.com

导入新项目

假设您有一个包含初始工作的压缩包 project.tar.gz。您可以按如下方式将其置于 Git 版本控制之下。

$ tar xzf project.tar.gz
$ cd project
$ git init

Git 会回复

Initialized empty Git repository in .git/

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

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

$ git add .

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

$ git commit

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

进行更改

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

$ git add file1 file2 file3

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

$ git diff --cached

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

$ git status
On branch master
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)

	modified:   file1
	modified:   file2
	modified:   file3

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

$ git commit

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

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

$ git commit -a

它会自动检测任何已修改（但不是新创建）的文件，将它们添加到索引并提交，所有操作一步完成。

关于提交消息的说明：虽然不是强制要求的，但最好在提交消息的开头写上一行简短的（不超过 50 个字符）摘要，然后是一个空行，接着是更详尽的描述。提交消息中到第一个空行之前的文本被视为提交标题，该标题在整个 Git 中使用。例如，git-format-patch[1] 将提交转换为电子邮件，它将标题放在“主题（Subject）”行中，将提交的其余部分放在正文中。

Git 跟踪内容而非文件

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

查看项目历史

您可以随时使用以下命令查看更改历史

$ git log

如果您还想在每一步查看完整的差异（diff），请使用

$ git log -p

通常，更改的概览有助于了解每一步的情况

$ git log --stat --summary

管理分支

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

$ git branch experimental

如果您现在运行

$ git branch

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

  experimental
* master

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

$ git switch experimental

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

(edit file)
$ git commit -a
$ git switch master

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

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

(edit file)
$ git commit -a

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

$ git merge experimental

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

$ git diff

将显示这一点。编辑文件解决冲突后，

$ git commit -a

将提交合并结果。最后，

$ gitk

将以漂亮的图形化方式显示生成的历史记录。

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

$ git branch -d experimental

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

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

$ git branch -D crazy-idea

分支成本低廉且简单，因此这是尝试新事物的绝佳方式。

使用 Git 进行协作

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

Bob 首先进行

bob$ git clone /home/alice/project myrepo

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

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

(edit files)
bob$ git commit -a
(repeat as necessary)

准备好后，他告诉 Alice 从 /home/bob/myrepo 处的仓库拉取更改。她通过以下方式完成此操作

alice$ cd /home/alice/project
alice$ git pull /home/bob/myrepo master

这会将 Bob 的 master 分支的更改合并到 Alice 的当前分支中。如果 Alice 在此期间自己也做了更改，那么她可能需要手动修复任何冲突。

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

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

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

alice$ git fetch /home/bob/myrepo master
alice$ git log -p HEAD..FETCH_HEAD

即使 Alice 有未提交的本地更改，此操作也是安全的。范围表示法 HEAD..FETCH_HEAD 的意思是“显示从 FETCH_HEAD 可达的所有内容，但排除从 HEAD 可达的任何内容”。Alice 已经知道通向她当前状态 (HEAD) 的所有内容，并使用此命令查看 Bob 的状态 (FETCH_HEAD) 中有哪些她尚未见过的内容。

如果 Alice 想要直观地查看自历史分叉以来 Bob 做了什么，她可以发出以下命令

$ gitk HEAD..FETCH_HEAD

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

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

$ gitk HEAD...FETCH_HEAD

这表示“显示可从其中任何一个到达的所有内容，但排除可从两者同时到达的任何内容”。

请注意，这些范围表示法既可以与 gitk 结合使用，也可以与 git log 结合使用。

在检查了 Bob 的工作之后，如果没有紧急的事情，Alice 可能会决定继续工作而不从 Bob 那里拉取。如果 Bob 的历史记录中确实有 Alice 立即需要的东西，Alice 可能会选择先暂存（stash）她正在进行的工作，执行 pull，最后在生成的历史记录之上取消暂存（unstash）她正在进行的工作。

当您在一个紧密团结的小组中工作时，反复与同一个仓库进行交互并不罕见。通过定义“远程仓库”简称，可以使操作更简单

alice$ git remote add bob /home/bob/myrepo

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

alice$ git fetch bob

与全写形式不同，当 Alice 使用通过 git remote 设置的远程仓库简称从 Bob 那里获取内容时，获取的内容存储在一个远程跟踪分支中，在本例中为 bob/master。所以在执行完这个操作后

alice$ git log -p master..bob/master

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

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

alice$ git merge bob/master

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

alice$ git pull . remotes/bob/master

请注意，无论命令行中还给出了什么，git pull 总是合并到当前分支中。

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

bob$ git pull

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

bob$ git config --get remote.origin.url
/home/alice/project

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

Git 还在 origin/master 名下保留了 Alice 的 master 分支的一个原始副本

bob$ git branch -r
  origin/master

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

bob$ git clone alice.org:/home/alice/project myrepo

或者，Git 有原生协议，也可以使用 http；详见 git-pull[1]。

Git 也可以在类似 CVS 的模式下使用，具有一个中央仓库，各个用户向其推送更改；参见 git-push[1] 和 gitcvs-migration[7]。

探索历史

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

$ git log
commit c82a22c39cbc32576f64f5c6b3f24b99ea8149c7
Author: Junio C Hamano <junkio@cox.net>
Date:   Tue May 16 17:18:22 2006 -0700

    merge-base: Clarify the comments on post processing.

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

$ git show c82a22c39cbc32576f64f5c6b3f24b99ea8149c7

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

$ git show c82a22c39c	# the first few characters of the name are
			# usually enough
$ git show HEAD		# the tip of the current branch
$ git show experimental	# the tip of the "experimental" branch

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

$ git show HEAD^  # to see the parent of HEAD
$ git show HEAD^^ # to see the grandparent of HEAD
$ git show HEAD~4 # to see the great-great grandparent of HEAD

请注意，合并提交可能具有多个父提交

$ git show HEAD^1 # show the first parent of HEAD (same as HEAD^)
$ git show HEAD^2 # show the second parent of HEAD

您也可以给提交起自己的名字；在运行了

$ git tag v2.5 1b2e1d63ff

之后，您可以通过名称 v2.5 引用 1b2e1d63ff。如果您打算与其他人共享此名称（例如，为了标识发布版本），您应该创建一个“标签（tag）”对象，并可能对其进行签名；详见 git-tag[1]。

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

$ git diff v2.5 HEAD	 # compare the current HEAD to v2.5
$ git branch stable v2.5 # start a new branch named "stable" based
			 # at v2.5
$ git reset --hard HEAD^ # reset your current branch and working
			 # directory to its state at HEAD^

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

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

$ git grep "hello" v2.5

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

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

$ git grep "hello"

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

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

$ git log v2.5..v2.6            # commits between v2.5 and v2.6
$ git log v2.5..                # commits since v2.5
$ git log --since="2 weeks ago" # commits from the last 2 weeks
$ git log v2.5.. Makefile       # commits since v2.5 which modify
				# Makefile

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

$ git log stable..master

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

$ git log master..stable

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

git log 命令有一个弱点：它必须以列表形式呈现提交。当历史记录中的开发路线分叉又合并在一起时，git log 呈现这些提交的顺序就没有意义了。

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

$ gitk --since="2 weeks ago" drivers/

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

最后，大多数接受文件名的命令都允许您在任何文件名前面加上一个提交，以指定该文件的特定版本

$ git diff v2.5:Makefile HEAD:Makefile.in

您也可以使用 git show 查看任何此类文件

$ git show v2.5:Makefile

后续步骤

本教程应该足以让您对项目进行基本的分布式版本控制。但是，要充分理解 Git 的深度和威力，您需要理解它所基于的两个简单概念

  • 对象数据库是一个非常优雅的系统，用于存储项目的历史记录——文件、目录和提交。

  • 索引文件是目录树状态的缓存，用于创建提交、检出工作目录以及保存合并中涉及的各种树。

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

如果您不想立即继续，那么此时可能感兴趣的其他一些离题内容包括

  • git-format-patch[1], git-am[1]：这些命令将一系列 git 提交转换为通过电子邮件发送的补丁，反之亦然，这对于像 Linux 内核这样严重依赖电子邮件补丁的项目非常有用。

  • git-bisect[1]：当您的项目中出现回归（regression）时，追踪错误的一种方法是通过搜索历史记录来找到导致错误的那个确切提交。git bisect 可以帮助您对该提交执行二分查找。它足够聪明，即使在具有大量合并分支的复杂非线性历史记录情况下，也能执行接近最优的搜索。

  • gitworkflows[7]：概述了推荐的工作流。

  • giteveryday[7]：每天 20 个命令左右的 Git 日常使用。

  • gitcvs-migration[7]：面向 CVS 用户的 Git。

另请参阅

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

GIT

Git[1] 套件的一部分