Git的基础入门

Git --everything-is-local

Git是一个免费的开源分布式版本控制系统，旨在快速高效地处理从小型到大型项目的所有内容。

Git易于学习，占地面积小，具有闪电般的快速性能。它具有诸如Subversion，CVS，Perforce和ClearCase之类的SCM工具，具有廉价的本地分支，方便的暂存区域和多个工作流等功能。

初次运行 Git 前的配置

Git 自带一个 git config 的工具来帮助设置控制 Git 外观和行为的配置变量。

/etc/gitconfig 文件: 包含系统上每一个用户及他们仓库的通用配置。
~/.gitconfig 或 ~/.config/git/config 文件：只针对当前用户。
当前使用仓库的 Git 目录中的 config 文件（即 .git/config）：针对该仓库。

你可以通过以下命令查看所有的配置以及它们所在的文件：

git config --list --show-origin

用户信息

×这很重要，安装完 Git 之后，要做的第一件事就是设置你的用户名和邮件地址。因为每一个 Git 提交都会使用这些信息，它们会写入到你的每一次提交中，不可更改：

git config --global user.name "hokori"

git config --global user.email hokori@hokori.cn

--global：该命令只需要运行一次，因为之后无论你在该系统上做任何事情， Git 都会使用那些信息。

获取 Git 仓库

通常有两种获取 Git 项目仓库的方式：

将尚未进行版本控制的本地目录转换为 Git 仓库；
从其它服务器克隆一个已存在的 Git 仓库。

在已存在目录中初始化仓库

mkdir ./my_project

cd my_project

git init

touch README.md

git add README.md

git commit -m "initial project version"

你已经得到了一个存在被追踪文件与初始提交的 Git 仓库。

克隆现有的仓库

隆仓库的命令是 git clone <url> 。比如，要克隆 Git 的链接库 libgit2，可以用下面的命令：

git clone https://github.com/libgit2/libgit2

如果你想在克隆远程仓库的时候，自定义本地仓库的名字，你可以通过额外的参数指定新的目录名：

git clone https://github.com/libgit2/libgit2 mylibgit

这会执行与上一条命令相同的操作，但目标目录名变为了 mylibgit。

记录每次更新到仓库

你工作目录下的每一个文件都不外乎这两种状态：已跟踪 或 未跟踪。

编辑过某些文件之后，由于自上次提交后你对它们做了修改，Git 将它们标记为已修改文件。在工作时，你可以选择性地将这些修改过的文件放入暂存区，然后提交所有已暂存的修改，如此反复。

检查当前文件状态

可以用 git status 命令查看哪些文件处于什么状态。如果在克隆仓库后立即使用此命令，会看到类似这样的输出：

$ git status

On branch master

Your branch is up-to-date with 'origin/master'.

nothing to commit, working directory clean

这说明你现在的工作目录相当干净。换句话说，所有已跟踪文件在上次提交后都未被更改过。此外，上面的信息还表明，当前目录下没有出现任何处于未跟踪状态的新文件，否则 Git 会在这里列出来。最后，该命令还显示了当前所在分支，并告诉你这个分支同远程服务器上对应的分支没有偏离。

现在，让我们在项目下创建一个新的 README 文件。如果之前并不存在这个文件，使用 git status 命令，你将看到一个新的未跟踪文件：

$ echo 'My Project' > README

$ git status

On branch master

Your branch is up-to-date with 'origin/master'.

Untracked files:

  (use "git add <file>..." to include in what will be committed)

    README

nothing added to commit but untracked files present (use "git add" to track)

在状态报告中可以看到新建的 README 文件出现在 Untracked files 下面。未跟踪的文件意味着 Git 在之前的快照（提交）中没有这些文件；Git 不会自动将之纳入跟踪范围，除非你明明白白地告诉它“我需要跟踪该文件”。这样的处理让你不必担心将生成的二进制文件或其它不想被跟踪的文件包含进来。不过现在的例子中，我们确实想要跟踪管理 README 这个文件。

跟踪新文件

使用命令 git add 开始跟踪一个文件。所以，要跟踪 README 文件，运行：

$ git add README

此时再运行 git status 命令，会看到 README 文件已被跟踪，并处于暂存状态：

$ git status

On branch master

Your branch is up-to-date with 'origin/master'.

Changes to be committed:

  (use "git restore --staged <file>..." to unstage)

    new file:   README

只要在 Changes to be committed 这行下面的，就说明是已暂存状态。如果此时提交，那么该文件在你运行 git add 时的版本将被留存在后续的历史记录中。你可能会想起之前我们使用 git init 后就运行了 git add <files> 命令，开始跟踪当前目录下的文件。 git add 命令使用文件或目录的路径作为参数；如果参数是目录的路径，该命令将递归地跟踪该目录下的所有文件。

暂存已修改的文件

现在我们来修改一个已被跟踪的文件。如果你修改了一个名为 CONTRIBUTING.md 的已被跟踪的文件，然后运行 git status 命令，会看到下面内容：

$ git status

On branch master

Your branch is up-to-date with 'origin/master'.

Changes to be committed:

  (use "git reset HEAD <file>..." to unstage)

    new file:   README

Changes not staged for commit:

  (use "git add <file>..." to update what will be committed)

  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   CONTRIBUTING.md

文件 CONTRIBUTING.md 出现在 Changes not staged for commit 这行下面，说明已跟踪文件的内容发生了变化，但还没有放到暂存区。要暂存这次更新，需要运行 git add 命令。这是个多功能命令：可以用它开始跟踪新文件，或者把已跟踪的文件放到暂存区，还能用于合并时把有冲突的文件标记为已解决状态等。将这个命令理解为“精确地将内容添加到下一次提交中”而不是“将一个文件添加到项目中”要更加合适。现在让我们运行 git add 将“CONTRIBUTING.md”放到暂存区，然后再看看 git status 的输出：

$ git add CONTRIBUTING.md

$ git status

On branch master

Your branch is up-to-date with 'origin/master'.

Changes to be committed:

  (use "git reset HEAD <file>..." to unstage)

    new file:   README

    modified:   CONTRIBUTING.md

现在两个文件都已暂存，下次提交时就会一并记录到仓库。假设此时，你想要在 CONTRIBUTING.md 里再加条注释。重新编辑存盘后，准备好提交。不过且慢，再运行 git status 看看：

$ vim CONTRIBUTING.md

$ git status

On branch master

Your branch is up-to-date with 'origin/master'.

Changes to be committed:

  (use "git reset HEAD <file>..." to unstage)

    new file:   README

    modified:   CONTRIBUTING.md

Changes not staged for commit:

  (use "git add <file>..." to update what will be committed)

  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   CONTRIBUTING.md

怎么回事？现在 CONTRIBUTING.md 文件同时出现在暂存区和非暂存区。这怎么可能呢？好吧，实际上 Git 只不过暂存了你运行 git add 命令时的版本。如果你现在提交，CONTRIBUTING.md 的版本是你最后一次运行 git add 命令时的那个版本，而不是你运行 git commit 时，在工作目录中的当前版本。所以，运行了 git add 之后又作了修订的文件，需要重新运行 git add 把最新版本重新暂存起来：

$ git add CONTRIBUTING.md

$ git status

On branch master

Your branch is up-to-date with 'origin/master'.

Changes to be committed:

  (use "git reset HEAD <file>..." to unstage)

    new file:   README

    modified:   CONTRIBUTING.md

状态简览

git status 命令的输出十分详细，但其用语有些繁琐。 Git 有一个选项可以帮你缩短状态命令的输出，这样可以以简洁的方式查看更改。如果你使用 git status -s 命令或 git status --short 命令，你将得到一种格式更为紧凑的输出。

$ git status -s

 M README

MM Rakefile

A  lib/git.rb

M  lib/simplegit.rb

?? LICENSE.txt

新添加的未跟踪文件前面有 ?? 标记，新添加到暂存区中的文件前面有 A 标记，修改过的文件前面有 M 标记。输出中有两栏，左栏指明了暂存区的状态，右栏指明了工作区的状态。例如，上面的状态报告显示： README 文件在工作区已修改但尚未暂存，而 lib/simplegit.rb 文件已修改且已暂存。 Rakefile 文件已修，暂存后又作了修改，因此该文件的修改中既有已暂存的部分，又有未暂存的部分。

忽略文件(`.gitignore`)

一般我们总会有些文件无需纳入 Git 的管理，也不希望它们总出现在未跟踪文件列表。在这种情况下，我们可以创建一个名为 .gitignore 的文件

来看一个实际的 .gitignore 例子：

$ cat .gitignore

*.[oa]

*~

第一行告诉 Git 忽略所有以 .o 或 .a 结尾的文件。第二行告诉 Git 忽略所有名字以波浪符（~）结尾的文件。

要养成一开始就为你的新仓库设置好 .gitignore 文件的习惯，以免将来误提交这类无用的文件。

文件 .gitignore 的格式规范如下：

所有空行或者以 # 开头的行都会被 Git 忽略。
可以使用标准的 glob 模式匹配，它会递归地应用在整个工作区中。
匹配模式可以以（/）开头防止递归。
匹配模式可以以（/）结尾指定目录。
要忽略指定模式以外的文件或目录，可以在模式前加上叹号（!）取反。

所谓的 glob 模式是指 shell 所使用的简化了的正则表达式。星号（*）匹配零个或多个任意字符；[abc] 匹配任何一个列在方括号中的字符（这个例子要么匹配一个 a，要么匹配一个 b，要么匹配一个 c）；问号（?）只匹配一个任意字符；如果在方括号中使用短划线分隔两个字符，表示所有在这两个字符范围内的都可以匹配（比如 [0-9] 表示匹配所有 0 到 9 的数字）。使用两个星号（**）表示匹配任意中间目录，比如 a/**/z 可以匹配 a/z 、 a/b/z 或 a/b/c/z 等。

我们再看一个 .gitignore 文件的例子：

# 忽略所有的 .a 文件

*.a

# 但跟踪所有的 lib.a，即便你在前面忽略了 .a 文件

!lib.a

# 只忽略当前目录下的 TODO 文件，而不忽略 subdir/TODO

/TODO

# 忽略任何目录下名为 build 的文件夹

build/

# 忽略 doc/notes.txt，但不忽略 doc/server/arch.txt

doc/*.txt

# 忽略 doc/ 目录及其所有子目录下的 .pdf 文件

doc/**/*.pdf

查看已暂存和未暂存的修改

如果 git status 命令的输出对于你来说过于简略，而你想知道具体修改了什么地方，可以用 git diff 命令。稍后我们会详细介绍 git diff，你通常可能会用它来回答这两个问题：当前做的哪些更新尚未暂存？有哪些更新已暂存并准备好下次提交？虽然 git status 已经通过在相应栏下列出文件名的方式回答了这个问题，但 git diff 能通过文件补丁的格式更加具体地显示哪些行发生了改变。

假如再次修改 README 文件后暂存，然后编辑 CONTRIBUTING.md 文件后先不暂存，运行 status 命令将会看到：

$ git status

On branch master

Your branch is up-to-date with 'origin/master'.

Changes to be committed:

  (use "git reset HEAD <file>..." to unstage)

    modified:   README

Changes not staged for commit:

  (use "git add <file>..." to update what will be committed)

  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   CONTRIBUTING.md

要查看尚未暂存的文件更新了哪些部分，不加参数直接输入 git diff：

$ git diff

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md

index 8ebb991..643e24f 100644

--- a/CONTRIBUTING.md

+++ b/CONTRIBUTING.md

@@ -65,7 +65,8 @@ branch directly, things can get messy.

 Please include a nice description of your changes when you submit your PR;

 if we have to read the whole diff to figure out why you're contributing

 in the first place, you're less likely to get feedback and have your change

-merged in.

+merged in. Also, split your changes into comprehensive chunks if your patch is

+longer than a dozen lines.

 If you are starting to work on a particular area, feel free to submit a PR

 that highlights your work in progress (and note in the PR title that it's

此命令比较的是工作目录中当前文件和暂存区域快照之间的差异。也就是修改之后还没有暂存起来的变化内容。

若要查看已暂存的将要添加到下次提交里的内容，可以用 git diff --staged 命令。这条命令将比对已暂存文件与最后一次提交的文件差异：

$ git diff --staged

diff --git a/README b/README

new file mode 100644

index 0000000..03902a1

--- /dev/null

+++ b/README

@@ -0,0 +1 @@

+My Project

请注意，git diff 本身只显示尚未暂存的改动，而不是自上次提交以来所做的所有改动。所以有时候你一下子暂存了所有更新过的文件，运行 git diff 后却什么也没有，就是这个原因。

像之前说的，暂存 CONTRIBUTING.md 后再编辑，可以使用 git status 查看已被暂存的修改或未被暂存的修改。如果我们的环境（终端输出）看起来如下：

$ git add CONTRIBUTING.md

$ echo '# test line' >> CONTRIBUTING.md

$ git status

On branch master

Your branch is up-to-date with 'origin/master'.

Changes to be committed:

  (use "git reset HEAD <file>..." to unstage)

    modified:   CONTRIBUTING.md

Changes not staged for commit:

  (use "git add <file>..." to update what will be committed)

  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   CONTRIBUTING.md

现在运行 git diff 看暂存前后的变化：

$ git diff

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md

index 643e24f..87f08c8 100644

--- a/CONTRIBUTING.md

+++ b/CONTRIBUTING.md

@@ -119,3 +119,4 @@ at the

 ## Starter Projects

 See our [projects list](https://github.com/libgit2/libgit2/blob/development/PROJECTS.md).

+# test line

然后用 git diff --cached 查看已经暂存起来的变化（ --staged 和 --cached 是同义词）：

$ git diff --cached

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md

index 8ebb991..643e24f 100644

--- a/CONTRIBUTING.md

+++ b/CONTRIBUTING.md

@@ -65,7 +65,8 @@ branch directly, things can get messy.

 Please include a nice description of your changes when you submit your PR;

 if we have to read the whole diff to figure out why you're contributing

 in the first place, you're less likely to get feedback and have your change

-merged in.

+merged in. Also, split your changes into comprehensive chunks if your patch is

+longer than a dozen lines.

 If you are starting to work on a particular area, feel free to submit a PR

 that highlights your work in progress (and note in the PR title that it's

提交更新

现在的暂存区已经准备就绪，可以提交了。在此之前，请务必确认还有什么已修改或新建的文件还没有 git add 过，否则提交的时候不会记录这些尚未暂存的变化。这些已修改但未暂存的文件只会保留在本地磁盘。所以，每次准备提交前，先用 git status 看下，你所需要的文件是不是都已暂存起来了，然后再运行提交命令 git commit：

git commit

这样会启动你选择的文本编辑器来输入提交说明。

编辑器会显示类似下面的文本信息（本例选用 Vim 的屏显方式展示）：

# Please enter the commit message for your changes. Lines starting

# with '#' will be ignored, and an empty message aborts the commit.

# On branch master

# Your branch is up-to-date with 'origin/master'.

#

# Changes to be committed:

#	new file:   README

#	modified:   CONTRIBUTING.md

#

~

~

~

".git/COMMIT_EDITMSG" 9L, 283C

可以看到，默认的提交消息包含最后一次运行 git status 的输出，放在注释行里，另外开头还有一个空行，供你输入提交说明。你完全可以去掉这些注释行，不过留着也没关系，多少能帮你回想起这次更新的内容有哪些。

退出编辑器时，Git 会丢弃注释行，用你输入的提交说明生成一次提交。

另外，你也可以在 commit 命令后添加 -m 选项，将提交信息与命令放在同一行，如下所示：

$ git commit -m "Story 182: Fix benchmarks for speed"

[master 463dc4f] Story 182: Fix benchmarks for speed

 2 files changed, 2 insertions(+)

 create mode 100644 README

好，现在你已经创建了第一个提交！可以看到，提交后它会告诉你，当前是在哪个分支（master）提交的，本次提交的完整 SHA-1 校验和是什么（463dc4f），以及在本次提交中，有多少文件修订过，多少行添加和删改过。

跳过使用暂存区域

尽管使用暂存区域的方式可以精心准备要提交的细节，但有时候这么做略显繁琐。 Git 提供了一个跳过使用暂存区域的方式，只要在提交的时候，给 git commit 加上 -a 选项，Git 就会自动把所有已经跟踪过的文件暂存起来一并提交，从而跳过 git add 步骤：

$ git status

On branch master

Your branch is up-to-date with 'origin/master'.

Changes not staged for commit:

  (use "git add <file>..." to update what will be committed)

  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   CONTRIBUTING.md

no changes added to commit (use "git add" and/or "git commit -a")

$ git commit -a -m 'added new benchmarks'

[master 83e38c7] added new benchmarks

 1 file changed, 5 insertions(+), 0 deletions(-)

看到了吗？提交之前不再需要 git add 文件“CONTRIBUTING.md”了。这是因为 -a 选项使本次提交包含了所有修改过的文件。这很方便，但是要小心，有时这个选项会将不需要的文件添加到提交中。

移除文件

要从 Git 中移除某个文件，就必须要从已跟踪文件清单中移除（确切地说，是从暂存区域移除），然后提交。可以用 git rm 命令完成此项工作，并连带从工作目录中删除指定的文件，这样以后就不会出现在未跟踪文件清单中了。

如果只是简单地从工作目录中手工删除文件，运行 git status 时就会在 “Changes not staged for commit” 部分（也就是 未暂存清单）看到：

$ rm PROJECTS.md

$ git status

On branch master

Your branch is up-to-date with 'origin/master'.

Changes not staged for commit:

  (use "git add/rm <file>..." to update what will be committed)

  (use "git checkout -- <file>..." to discard changes in working directory)

        deleted:    PROJECTS.md

no changes added to commit (use "git add" and/or "git commit -a")

然后再运行 git rm 记录此次移除文件的操作：

$ git rm PROJECTS.md

rm 'PROJECTS.md'

$ git status

On branch master

Your branch is up-to-date with 'origin/master'.

Changes to be committed:

  (use "git reset HEAD <file>..." to unstage)

    deleted:    PROJECTS.md

下一次提交时，该文件就不再纳入版本管理了。如果要删除之前修改过或已经放到暂存区的文件，则必须使用强制删除选项 -f（译注：即 force 的首字母）。这是一种安全特性，用于防止误删尚未添加到快照的数据，这样的数据不能被 Git 恢复。

另外一种情况是，我们想把文件从 Git 仓库中删除（亦即从暂存区域移除），但仍然希望保留在当前工作目录中。换句话说，你想让文件保留在磁盘，但是并不想让 Git 继续跟踪。当你忘记添加 .gitignore 文件，不小心把一个很大的日志文件或一堆 .a 这样的编译生成文件添加到暂存区时，这一做法尤其有用。为达到这一目的，使用 --cached 选项：

$ git rm --cached README

git rm 命令后面可以列出文件或者目录的名字，也可以使用 glob 模式。比如：

$ git rm log/\*.log

注意到星号 * 之前的反斜杠 \，因为 Git 有它自己的文件模式扩展匹配方式，所以我们不用 shell 来帮忙展开。此命令删除 log/ 目录下扩展名为 .log 的所有文件。类似的比如：

$ git rm \*~

该命令会删除所有名字以 ~ 结尾的文件。

移动文件

不像其它的 VCS 系统，Git 并不显式跟踪文件移动操作。如果在 Git 中重命名了某个文件，仓库中存储的元数据并不会体现出这是一次改名操作。不过 Git 非常聪明，它会推断出究竟发生了什么，至于具体是如何做到的，我们稍后再谈。

既然如此，当你看到 Git 的 mv 命令时一定会困惑不已。要在 Git 中对文件改名，可以这么做：

$ git mv file_from file_to

它会恰如预期般正常工作。实际上，即便此时查看状态信息，也会明白无误地看到关于重命名操作的说明：

$ git mv README.md README

$ git status

On branch master

Your branch is up-to-date with 'origin/master'.

Changes to be committed:

  (use "git reset HEAD <file>..." to unstage)

    renamed:    README.md -> README

其实，运行 git mv 就相当于运行了下面三条命令：

$ mv README.md README

$ git rm README.md

$ git add README

如此分开操作，Git 也会意识到这是一次重命名，所以不管何种方式结果都一样。两者唯一的区别是，mv 是一条命令而非三条命令，直接用 git mv 方便得多。不过有时候用其他工具批处理重命名的话，要记得在提交前删除旧的文件名，再添加新的文件名。

查看提交历史

在提交了若干更新，又或者克隆了某个项目之后，你也许想回顾下提交历史。完成这个任务最简单而又有效的工具是 git log 命令。

git log 有许多选项可以帮助你搜寻你所要找的提交，下面我们会介绍几个最常用的选项。

git log

其中一个比较有用的选项是 -p 或 --patch ，它会显示每次提交所引入的差异（按补丁的格式输出）。

git log -p -2

你也可以为 git log 附带一系列的总结性选项。比如你想看到每次提交的简略统计信息，可以使用 --stat 选项。--stat 选项在每次提交的下面列出所有被修改过的文件、有多少文件被修改了以及被修改过的文件的哪些行被移除或是添加了。在每次提交的最后还有一个总结。

另一个非常有用的选项是 --pretty。这个选项可以使用不同于默认格式的方式展示提交历史。这个选项有一些内建的子选项供你使用。比如 oneline 会将每个提交放在一行显示，在浏览大量的提交时非常有用。另外还有 short，full 和 fuller 选项，它们展示信息的格式基本一致，但是详尽程度不一：

$ git log --pretty=oneline

ca82a6dff817ec66f44342007202690a93763949 changed the version number

085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7 removed unnecessary test

a11bef06a3f659402fe7563abf99ad00de2209e6 first commit

最有意思的是 format ，可以定制记录的显示格式。这样的输出对后期提取分析格外有用——因为你知道输出的格式不会随着 Git 的更新而发生改变：

$ git log --pretty=format:"%h - %an, %ar : %s"

ca82a6d - Scott Chacon, 6 years ago : changed the version number

085bb3b - Scott Chacon, 6 years ago : removed unnecessary test

a11bef0 - Scott Chacon, 6 years ago : first commit

git log --pretty=format 常用的选项列出了 format 接受的常用格式占位符的写法及其代表的意义。

选项	说明
`%H`	提交的完整哈希值
`%h`	提交的简写哈希值
`%T`	树的完整哈希值
`%t`	树的简写哈希值
`%P`	父提交的完整哈希值
`%p`	父提交的简写哈希值
`%an`	作者名字
`%ae`	作者的电子邮件地址
`%ad`	作者修订日期（可以用 --date=选项来定制格式）
`%ar`	作者修订日期，按多久以前的方式显示
`%cn`	提交者的名字
`%ce`	提交者的电子邮件地址
`%cd`	提交日期
`%cr`	提交日期（距今多长时间）
`%s`	提交说明

你一定奇怪作者和 提交者 之间究竟有何差别，其实作者指的是实际作出修改的人，提交者指的是最后将此工作成果提交到仓库的人。所以，当你为某个项目发布补丁，然后某个核心成员将你的补丁并入项目时，你就是作者，而那个核心成员就是提交者。我们会在分布式 Git 再详细介绍两者之间的细微差别。

当 oneline 或 format 与另一个 log 选项 --graph 结合使用时尤其有用。这个选项添加了一些 ASCII 字符串来形象地展示你的分支、合并历史：

$ git log --pretty=format:"%h %s" --graph

* 2d3acf9 ignore errors from SIGCHLD on trap

*  5e3ee11 Merge branch 'master' of git://github.com/dustin/grit

|\

| * 420eac9 Added a method for getting the current branch.

* | 30e367c timeout code and tests

* | 5a09431 add timeout protection to grit

* | e1193f8 support for heads with slashes in them

|/

* d6016bc require time for xmlschema

*  11d191e Merge branch 'defunkt' into local

这种输出类型会在我们下一章学完分支与合并以后变得更加有趣。

以上只是简单介绍了一些 git log 命令支持的选项。 git log 的常用选项列出了我们目前涉及到的和没涉及到的选项，以及它们是如何影响 log 命令的输出的：

选项	说明
`-p`	按补丁格式显示每个提交引入的差异。
`--stat`	显示每次提交的文件修改统计信息。
`--shortstat`	只显示 --stat 中最后的行数修改添加移除统计。
`--name-only`	仅在提交信息后显示已修改的文件清单。
`--name-status`	显示新增、修改、删除的文件清单。
`--abbrev-commit`	仅显示 SHA-1 校验和所有 40 个字符中的前几个字符。
`--relative-date`	使用较短的相对时间而不是完整格式显示日期（比如“2 weeks ago”）。
`--graph`	在日志旁以 ASCII 图形显示分支与合并历史。
`--pretty`	使用其他格式显示历史提交信息。可用的选项包括 oneline、short、full、fuller 和 format（用来定义自己的格式）。
`--oneline`	`--pretty=oneline --abbrev-commit` 合用的简写。

限制输出长度

除了定制输出格式的选项之外，git log 还有许多非常实用的限制输出长度的选项，也就是只输出一部分的提交。之前你已经看到过 -2 选项了，它只会显示最近的两条提交，实际上，你可以使用类似 -<n> 的选项，其中的 n 可以是任何整数，表示仅显示最近的 n 条提交。不过实践中这个选项不是很常用，因为 Git 默认会将所有的输出传送到分页程序中，所以你一次只会看到一页的内容。

但是，类似 --since 和 --until 这种按照时间作限制的选项很有用。例如，下面的命令会列出最近两周的所有提交：

$ git log --since=2.weeks

该命令可用的格式十分丰富——可以是类似 "2008-01-15" 的具体的某一天，也可以是类似 "2 years 1 day 3 minutes ago" 的相对日期。

还可以过滤出匹配指定条件的提交。用 --author 选项显示指定作者的提交，用 --grep 选项搜索提交说明中的关键字。

Note	你可以指定多个 `--author` 和 `--grep` 搜索条件，这样会只输出任意匹配 `--author` 模式和 `--grep` 模式的提交。然而，如果你添加了 `--all-match` 选项，则只会输出所有匹配 `--grep` 模式的提交。

另一个非常有用的过滤器是 -S（俗称“pickaxe”选项，取“用鹤嘴锄在土里捡石头”之意），它接受一个字符串参数，并且只会显示那些添加或删除了该字符串的提交。假设你想找出添加或删除了对某一个特定函数的引用的提交，可以调用：

$ git log -S function_name

最后一个很实用的 git log 选项是路径（path），如果只关心某些文件或者目录的历史提交，可以在 git log 选项的最后指定它们的路径。因为是放在最后位置上的选项，所以用两个短划线（--）隔开之前的选项和后面限定的路径名。

在限制 git log 输出的选项中列出了常用的选项

选项	说明
`-<n>`	仅显示最近的 n 条提交。
`--since`, `--after`	仅显示指定时间之后的提交。
`--until`, `--before`	仅显示指定时间之前的提交。
`--author`	仅显示作者匹配指定字符串的提交。
`--committer`	仅显示提交者匹配指定字符串的提交。
`--grep`	仅显示提交说明中包含指定字符串的提交。
`-S`	仅显示添加或删除内容匹配指定字符串的提交。

来看一个实际的例子，如果要在 Git 源码库中查看 Junio Hamano 在 2008 年 10 月其间，除了合并提交之外的哪一个提交修改了测试文件，可以使用下面的命令：

$ git log --pretty="%h - %s" --author='Junio C Hamano' --since="2008-10-01" \

   --before="2008-11-01" --no-merges -- t/

5610e3b - Fix testcase failure when extended attributes are in use

acd3b9e - Enhance hold_lock_file_for_{update,append}() API

f563754 - demonstrate breakage of detached checkout with symbolic link HEAD

d1a43f2 - reset --hard/read-tree --reset -u: remove unmerged new paths

51a94af - Fix "checkout --track -b newbranch" on detached HEAD

b0ad11e - pull: allow "git pull origin $something:$current_branch" into an unborn branch

在近 40000 条提交中，上面的输出仅列出了符合条件的 6 条记录。

隐藏合并提交

按照你代码仓库的工作流程，记录中可能有为数不少的合并提交，它们所包含的信息通常并不多。为了避免显示的合并提交弄乱历史记录，可以为 log 加上 --no-merges 选项。

撤消操作

在任何一个阶段，你都有可能想要撤消某些操作。这里，我们将会学习几个撤消你所做修改的基本工具。注意，有些撤消操作是不可逆的。这是在使用 Git 的过程中，会因为操作失误而导致之前的工作丢失的少有的几个地方之一。

有时候我们提交完了才发现漏掉了几个文件没有添加，或者提交信息写错了。此时，可以运行带有 --amend 选项的提交命令来重新提交：

$ git commit --amend

这个命令会将暂存区中的文件提交。如果自上次提交以来你还未做任何修改（例如，在上次提交后马上执行了此命令），那么快照会保持不变，而你所修改的只是提交信息。

文本编辑器启动后，可以看到之前的提交信息。编辑后保存会覆盖原来的提交信息。

例如，你提交后发现忘记了暂存某些需要的修改，可以像下面这样操作：

$ git commit -m 'initial commit'

$ git add forgotten_file

$ git commit --amend

最终你只会有一个提交——第二次提交将代替第一次提交的结果。

当你在修补最后的提交时，并不是通过用改进后的提交 原位替换 掉旧有提交的方式来修复的，理解这一点非常重要。从效果上来说，就像是旧有的提交从未存在过一样，它并不会出现在仓库的历史中。

修补提交最明显的价值是可以稍微改进你最后的提交，而不会让“啊，忘了添加一个文件”或者 “小修补，修正笔误”这种提交信息弄乱你的仓库历史。

取消暂存的文件

接下来的两个小节演示如何操作暂存区和工作目录中已修改的文件。这些命令在修改文件状态的同时，也会提示如何撤消操作。例如，你已经修改了两个文件并且想要将它们作为两次独立的修改提交，但是却意外地输入 git add * 暂存了它们两个。如何只取消暂存两个中的一个呢？ git status 命令提示了你：

$ git add *

$ git status

On branch master

Changes to be committed:

  (use "git reset HEAD <file>..." to unstage)

    renamed:    README.md -> README

    modified:   CONTRIBUTING.md

在 “Changes to be committed” 文字正下方，提示使用 git reset HEAD <file>... 来取消暂存。所以，我们可以这样来取消暂存 CONTRIBUTING.md 文件：

$ git reset HEAD CONTRIBUTING.md

Unstaged changes after reset:

M	CONTRIBUTING.md

$ git status

On branch master

Changes to be committed:

  (use "git reset HEAD <file>..." to unstage)

    renamed:    README.md -> README

Changes not staged for commit:

  (use "git add <file>..." to update what will be committed)

  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   CONTRIBUTING.md

这个命令有点儿奇怪，但是起作用了。 CONTRIBUTING.md 文件已经是修改未暂存的状态了。

git reset 确实是个危险的命令，如果加上了 --hard 选项则更是如此。然而在上述场景中，工作目录中的文件尚未修改，因此相对安全一些。

到目前为止这个神奇的调用就是你需要对 git reset 命令了解的全部。我们将会在重置揭密中了解 reset 的更多细节以及如何掌握它做一些真正有趣的事。

撤消对文件的修改

如果你并不想保留对 CONTRIBUTING.md 文件的修改怎么办？你该如何方便地撤消修改——将它还原成上次提交时的样子（或者刚克隆完的样子，或者刚把它放入工作目录时的样子）？幸运的是，git status 也告诉了你应该如何做。在最后一个例子中，未暂存区域是这样：

Changes not staged for commit:

  (use "git add <file>..." to update what will be committed)

  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   CONTRIBUTING.md

它非常清楚地告诉了你如何撤消之前所做的修改。让我们来按照提示执行：

$ git checkout -- CONTRIBUTING.md

$ git status

On branch master

Changes to be committed:

  (use "git reset HEAD <file>..." to unstage)

    renamed:    README.md -> README

可以看到那些修改已经被撤消了。

请务必记得 git checkout -- <file> 是一个危险的命令。你对那个文件在本地的任何修改都会消失——Git 会用最近提交的版本覆盖掉它。除非你确实清楚不想要对那个文件的本地修改了，否则请不要使用这个命令。

如果你仍然想保留对那个文件做出的修改，但是现在仍然需要撤消，我们将会在 Git 分支介绍保存进度与分支，这通常是更好的做法。

记住，在 Git 中任何 已提交 的东西几乎总是可以恢复的。甚至那些被删除的分支中的提交或使用 --amend 选项覆盖的提交也可以恢复（阅读数据恢复了解数据恢复）。然而，任何你未提交的东西丢失后很可能再也找不到了。

远程仓库的使用

为了能在任意 Git 项目上协作，你需要知道如何管理自己的远程仓库。远程仓库是指托管在因特网或其他网络中的你的项目的版本库。你可以有好几个远程仓库，通常有些仓库对你只读，有些则可以读写。与他人协作涉及管理远程仓库以及根据需要推送或拉取数据。管理远程仓库包括了解如何添加远程仓库、移除无效的远程仓库、管理不同的远程分支并定义它们是否被跟踪等等。在本节中，我们将介绍一部分远程管理的技能。

远程仓库可以在你的本地主机上

你完全可以在一个“远程”仓库上工作，而实际上它在你本地的主机上。词语“远程”未必表示仓库在网络或互联网上的其它位置，而只是表示它在别处。在这样的远程仓库上工作，仍然需要和其它远程仓库上一样的标准推送、拉取和抓取操作。

如果想查看你已经配置的远程仓库服务器，可以运行 git remote 命令。它会列出你指定的每一个远程服务器的简写。如果你已经克隆了自己的仓库，那么至少应该能看到 origin ——这是 Git 给你克隆的仓库服务器的默认名字：

$ git clone https://github.com/schacon/ticgit

Cloning into 'ticgit'...

remote: Reusing existing pack: 1857, done.

remote: Total 1857 (delta 0), reused 0 (delta 0)

Receiving objects: 100% (1857/1857), 374.35 KiB | 268.00 KiB/s, done.

Resolving deltas: 100% (772/772), done.

Checking connectivity... done.

$ cd ticgit

$ git remote

origin

你也可以指定选项 -v，会显示需要读写远程仓库使用的 Git 保存的简写与其对应的 URL。

$ git remote -v

origin	https://github.com/schacon/ticgit (fetch)

origin	https://github.com/schacon/ticgit (push)

如果你的远程仓库不止一个，该命令会将它们全部列出。例如，与几个协作者合作的，拥有多个远程仓库的仓库看起来像下面这样：

$ cd grit

$ git remote -v

bakkdoor  https://github.com/bakkdoor/grit (fetch)

bakkdoor  https://github.com/bakkdoor/grit (push)

cho45     https://github.com/cho45/grit (fetch)

cho45     https://github.com/cho45/grit (push)

defunkt   https://github.com/defunkt/grit (fetch)

defunkt   https://github.com/defunkt/grit (push)

koke      git://github.com/koke/grit.git (fetch)

koke      git://github.com/koke/grit.git (push)

origin    git@github.com:mojombo/grit.git (fetch)

origin    git@github.com:mojombo/grit.git (push)

这表示我们能非常方便地拉取其它用户的贡献。我们还可以拥有向他们推送的权限，这里暂不详述。

注意这些远程仓库使用了不同的协议。我们将会在在服务器上搭建 Git 中了解关于它们的更多信息。

添加远程仓库

我们在之前的章节中已经提到并展示了 git clone 命令是如何自行添加远程仓库的，不过这里将告诉你如何自己来添加它。运行 git remote add <shortname> <url> 添加一个新的远程 Git 仓库，同时指定一个方便使用的简写：

$ git remote

origin

$ git remote add pb https://github.com/paulboone/ticgit

$ git remote -v

origin	https://github.com/schacon/ticgit (fetch)

origin	https://github.com/schacon/ticgit (push)

pb	https://github.com/paulboone/ticgit (fetch)

pb	https://github.com/paulboone/ticgit (push)

现在你可以在命令行中使用字符串 pb 来代替整个 URL。例如，如果你想拉取 Paul 的仓库中有但你没有的信息，可以运行 git fetch pb：

$ git fetch pb

remote: Counting objects: 43, done.

remote: Compressing objects: 100% (36/36), done.

remote: Total 43 (delta 10), reused 31 (delta 5)

Unpacking objects: 100% (43/43), done.

From https://github.com/paulboone/ticgit

 * [new branch]      master     -> pb/master

 * [new branch]      ticgit     -> pb/ticgit

现在 Paul 的 master 分支可以在本地通过 pb/master 访问到——你可以将它合并到自己的某个分支中，或者如果你想要查看它的话，可以检出一个指向该点的本地分支。（我们将会在 Git 分支中详细介绍什么是分支以及如何使用分支。）

从远程仓库中抓取与拉取

就如刚才所见，从远程仓库中获得数据，可以执行：

$ git fetch <remote>

这个命令会访问远程仓库，从中拉取所有你还没有的数据。执行完成后，你将会拥有那个远程仓库中所有分支的引用，可以随时合并或查看。

如果你使用 clone 命令克隆了一个仓库，命令会自动将其添加为远程仓库并默认以 “origin” 为简写。所以，git fetch origin 会抓取克隆（或上一次抓取）后新推送的所有工作。必须注意 git fetch 命令只会将数据下载到你的本地仓库——它并不会自动合并或修改你当前的工作。当准备好时你必须手动将其合并入你的工作。

如果你的当前分支设置了跟踪远程分支（阅读下一节和 Git 分支了解更多信息），那么可以用 git pull 命令来自动抓取后合并该远程分支到当前分支。这或许是个更加简单舒服的工作流程。默认情况下，git clone 命令会自动设置本地 master 分支跟踪克隆的远程仓库的 master 分支（或其它名字的默认分支）。运行 git pull 通常会从最初克隆的服务器上抓取数据并自动尝试合并到当前所在的分支。

推送到远程仓库

当你想分享你的项目时，必须将其推送到上游。这个命令很简单：git push <remote> <branch>。当你想要将 master 分支推送到 origin 服务器时（再次说明，克隆时通常会自动帮你设置好那两个名字），那么运行这个命令就可以将你所做的备份到服务器：

$ git push origin master

只有当你有所克隆服务器的写入权限，并且之前没有人推送过时，这条命令才能生效。当你和其他人在同一时间克隆，他们先推送到上游然后你再推送到上游，你的推送就会毫无疑问地被拒绝。你必须先抓取他们的工作并将其合并进你的工作后才能推送。阅读 Git 分支了解如何推送到远程仓库服务器的详细信息。

查看某个远程仓库

如果想要查看某一个远程仓库的更多信息，可以使用 git remote show <remote> 命令。如果想以一个特定的缩写名运行这个命令，例如 origin，会得到像下面类似的信息：

$ git remote show origin

* remote origin

  Fetch URL: https://github.com/schacon/ticgit

  Push  URL: https://github.com/schacon/ticgit

  HEAD branch: master

  Remote branches:

    master                               tracked

    dev-branch                           tracked

  Local branch configured for 'git pull':

    master merges with remote master

  Local ref configured for 'git push':

    master pushes to master (up to date)

它同样会列出远程仓库的 URL 与跟踪分支的信息。这些信息非常有用，它告诉你正处于 master 分支，并且如果运行 git pull，就会抓取所有的远程引用，然后将远程 master 分支合并到本地 master 分支。它也会列出拉取到的所有远程引用。

这是一个经常遇到的简单例子。如果你是 Git 的重度使用者，那么还可以通过 git remote show 看到更多的信息。

$ git remote show origin

* remote origin

  URL: https://github.com/my-org/complex-project

  Fetch URL: https://github.com/my-org/complex-project

  Push  URL: https://github.com/my-org/complex-project

  HEAD branch: master

  Remote branches:

    master                           tracked

    dev-branch                       tracked

    markdown-strip                   tracked

    issue-43                         new (next fetch will store in remotes/origin)

    issue-45                         new (next fetch will store in remotes/origin)

    refs/remotes/origin/issue-11     stale (use 'git remote prune' to remove)

  Local branches configured for 'git pull':

    dev-branch merges with remote dev-branch

    master     merges with remote master

  Local refs configured for 'git push':

    dev-branch                     pushes to dev-branch                     (up to date)

    markdown-strip                 pushes to markdown-strip                 (up to date)

    master                         pushes to master                         (up to date)

这个命令列出了当你在特定的分支上执行 git push 会自动地推送到哪一个远程分支。它也同样地列出了哪些远程分支不在你的本地，哪些远程分支已经从服务器上移除了，还有当你执行 git pull 时哪些本地分支可以与它跟踪的远程分支自动合并。

远程仓库的重命名与移除

你可以运行 git remote rename 来修改一个远程仓库的简写名。例如，想要将 pb 重命名为 paul，可以用 git remote rename 这样做：

$ git remote rename pb paul

$ git remote

origin

paul

值得注意的是这同样也会修改你所有远程跟踪的分支名字。那些过去引用 pb/master 的现在会引用 paul/master。

如果因为一些原因想要移除一个远程仓库——你已经从服务器上搬走了或不再想使用某一个特定的镜像了，又或者某一个贡献者不再贡献了——可以使用 git remote remove 或 git remote rm ：

$ git remote remove paul

$ git remote

origin

一旦你使用这种方式删除了一个远程仓库，那么所有和这个远程仓库相关的远程跟踪分支以及配置信息也会一起被删除。