1
0
Fork 0

Merge pull request #45 from dotnil/gh-pages

Use normal you (你) instead of honorific you (您)
gh-pages
Matthew McCullough 11 years ago
commit b4179f8609

@ -3,6 +3,6 @@ Online Git Reference
I've been giving out git reference cards and wanted a sort of online version
of that. A list of the common commands, grouped by task, with the common
invocations in an easy to reference site. This is my shot at that site -
invocations in an easy to reference site. This is my shot at that site -
hopefully it is a nice way to get into this stuff if someone is intimidated
by the pro git book.

@ -4,5 +4,6 @@ layout: zh_reference
<div class="box">
<h2>谁的作品?</h2>
<br/>
<p>Git 参考手册是 Github 项目组的成果。<a href="http://cyj.me">逸才</a><a href="http://gitref.org">Git Reference</a> 的基础上做了中文翻译。</p>
<p>Git 参考手册是 Github 项目组的成果。</p>
<p><a href="http://cyj.me">逸才</a><a href="http://gitref.org">Git Reference</a> 的基础上做了中文翻译。</p>
</div>

@ -11,15 +11,17 @@ layout: zh_reference
</h2>
<div class="block">
<p>
Git 的工作就是创建和保存您的项目的快照并和之后的快照进行对比。本章将对有关创建与提交您的项目的快照的命令作介绍。
Git 的工作就是创建和保存你的项目的快照及与之后的快照进行对比。本章将对有关创建与提交你的项目的快照的命令作介绍。
</p>
<p>
这里有个重要的概念Git 有一个叫做“索引”的东东,有点像是您的快照的缓存区。这使得Git能够很方便的从更改的文件中创建出一系列的快照,而不是一次提交所有的更改。
这里有个重要的概念Git 有一个叫做“索引”的东东,有点像是你的快照的缓存区。这就使你能够从更改的文件中创建出一系列组织良好的快照,而不是一次提交所有的更改。
</p>
<p class="nutshell">
<strong>简而言之</strong>,使用 <code>git add</code> 添加需要追踪的新文件和待提交的更改,然后使用 <code>git status</code><code>git diff</code> 查看有何改动,最后用 <code>git commit</code> 将您的快照记录。这就是您要用的基本流程,绝大部分时候都是这样的。
<strong>简而言之</strong>,使用 <code>git add</code> 添加需要追踪的新文件和待提交的更改,
然后使用 <code>git status</code><code>git diff</code> 查看有何改动,
最后用 <code>git commit</code> 将你的快照记录。这就是你要用的基本流程,绝大部分时候都是这样的。
</p>
</div>
@ -36,11 +38,14 @@ layout: zh_reference
</h2>
<div class="block">
<p>
在 Git 中,在提交您修改的文件之前,您需要把它们添加到缓存。如果该文件是新创建的,您可以执行 <code>git add</code> 将该文件添加到缓存,但是,即使该文件已经被追踪了 —— 也就是说,曾经提交过了 —— 你仍然需要执行 <cpde>git add</code> 将新更改的文件添加到缓存去。让我们看几个例子:
<p>
在 Git 中,在提交你修改的文件之前,你需要把它们添加到缓存。如果该文件是新创建的,你可以执行
<code>git add</code> 将该文件添加到缓存,但是,即使该文件已经被追踪了 —— 也就是说,曾经提交过了 ——
你仍然需要执行 <cpde>git add</code> 将新更改的文件添加到缓存去。让我们看几个例子:
</p>
<p>回到我们的 Hello World 示例,初始化该项目之后,我们就要用 <code>git add</code> 将我们的文件添加进去了。我们可以用 <code>git status</code> 看看我们的项目的当前状态。
<p>回到我们的 Hello World 示例,初始化该项目之后,我们就要用 <code>git add</code> 将我们的文件添加进去了。
我们可以用 <code>git status</code> 看看我们的项目的当前状态。
</p>
<pre>
@ -49,13 +54,13 @@ layout: zh_reference
<span class="red">??</span> hello.rb
</pre>
我们有俩尚未被追踪的文件,得添加一下。
<p>我们有俩尚未被追踪的文件,得添加一下。</p>
<pre>
<b>$ git add README hello.rb</b>
</pre>
现在我们再执行 <code>git status</code>,就可以看到这俩文件已经加上去了。
<p>现在我们再执行 <code>git status</code>,就可以看到这俩文件已经加上去了。</p>
<pre>
<b>$ git status -s</b>
@ -64,10 +69,14 @@ layout: zh_reference
</pre>
<p class="aside">
新项目中,添加所有文件很普遍,可以在当前工作目录执行命令:<code>git add .</code>。因为 Git 会递归地将您执行命令时所在的目录中的所有文件添加上去,所以如果你将当前的工作目录作为参数,它就会追踪那儿的所有文件了。如此,<code>git add .</code> 就和 <code>git add README hello.rb</code> 有一样的效果。此外,效果一致的还有 <code>git add *</code>,不过那只是因为我们这还木有子目录,不需要递归地添加新文件。
新项目中,添加所有文件很普遍,可以在当前工作目录执行命令:<code>git add .</code>
因为 Git 会递归地将你执行命令时所在的目录中的所有文件添加上去,所以如果你将当前的工作目录作为参数,
它就会追踪那儿的所有文件了。如此,<code>git add .</code> 就和 <code>git add README hello.rb</code>
有一样的效果。
此外,效果一致的还有 <code>git add *</code>,不过那只是因为我们这还木有子目录,不需要递归地添加新文件。
</p>
<p>好了,现在我们改个文件,再跑一下 <code>git status</code>,有点古怪。</p>
<p>好了,现在我们改个文件,再跑一下 <code>git status</code>,有点古怪。</p>
<pre>
<b>$ vim README</b>
<b>$ git status -s</b>
@ -75,17 +84,19 @@ layout: zh_reference
<span class="green">A</span> hello.rb
</pre>
<p>
“AM” 状态的意思是,这个文件在我们将它添加到缓存之后又有改动。这意味着如果我们现在提交快照,我们提交的将是上次执行 <code>git add</code> 的时候的文件版本而不是现在在磁盘中的这个。Git 并不认为磁盘中的文件与您想快照的文件必须是一致的 —— (如果您需要它们一致,)得用 <code>git add</code> 命令告诉它。
<p>“AM” 状态的意思是,这个文件在我们将它添加到缓存之后又有改动。这意味着如果我们现在提交快照,
我们记录的将是上次跑 <code>git add</code> 的时候的文件版本,而不是现在在磁盘中的这个。
Git 并不认为磁盘中的文件与你想快照的文件必须是一致的 —— (如果你需要它们一致,)得用 <code>git add</code> 命令告诉它。
</p>
<p class="nutshell">
<strong>简而言之</strong>
当您想要将您的修改包含在即将提交的快照里的时候,执行 <code>git add</code>。任何您没有添加的改动都不会被包含在内 —— 这意味着您可以比其他的绝大多数源代码版本控制系统更精确地控制您的快照。
<strong>一言以蔽之</strong>
当你要将你的修改包含在即将提交的快照里的时候,执行 <code>git add</code>
任何你没有添加的改动都不会被包含在内 —— 这意味着你可以比绝大多数其他源代码版本控制系统更精确地归置你的快照。
</p>
<p>请查看《Pro Git》中 <code>git add</code> 的 “-p” 参数,以了解更多关于提交文件的灵活性的例子。
</p>
<p>请查看《Pro Git》中 <code>git add</code> 的 “-p” 参数,以了解更多关于提交文件的灵活性的例子。
</p>
</div>
@ -98,11 +109,14 @@ layout: zh_reference
<a target="new" href="http://progit.org/book/ch2-2.html#checking_the_status_of_your_files"></a>
</span>
<a name="status">git status</a>
<span class="desc">查看的文件在工作目录与缓存的状态</span>
<span class="desc">查看的文件在工作目录与缓存的状态</span>
</h2>
<div class="block">
<p>正如您在 <code>git add</code> 小节中所看到的,您可以执行 <code>git status</code> 命令查看您的代码在缓存与当前工作目录的状态。我演示该命令的时候加了 <code>-s</code> 参数,以获得简短的结果输出。若没有这个标记,命令 <code>git status</code> 将告诉您更多的提示与上下文信息。以下便是同样状态下,有跟没有 <code>-s</code> 参数的输出对比。简短的输出如下:
<p>正如你在 <code>git add</code> 小节中所看到的,你可以执行 <code>git status</code>
命令查看你的代码在缓存与当前工作目录的状态。我演示该命令的时候加了 <code>-s</code> 参数,以获得简短的结果输出。
若没有这个标记,命令 <code>git status</code> 将告诉你更多的提示与上下文欣喜。
以下便是同样状态下,有跟没有 <code>-s</code> 参数的输出对比。简短的输出如下:
</p>
<pre>
@ -111,7 +125,7 @@ layout: zh_reference
<span class="green">A</span> hello.rb
</pre>
而同样的状态,详细的输出看起来是这样的:
<p>而同样的状态,详细的输出看起来是这样的:</p>
<pre>
<b>$ git status</b>
@ -133,10 +147,10 @@ layout: zh_reference
#
</pre>
<p>您很容易发现简短的输出看起来很紧凑。而详细输出则很有帮助,提示您可以用何种命令完成您接下来可能要做的事情。
<p>你很容易发现简短的输出看起来很紧凑。而详细输出则很有帮助,提示你可以用何种命令完成你接下来可能要做的事情。
</p>
<p>Git 还会告诉您在您上次提交之后,有哪些文件被删除、修改或者存入缓存了。</p>
<p>Git 还会告诉你在你上次提交之后,有哪些文件被删除、修改或者存入缓存了。</p>
<pre>
<b>$ git status -s</b>
@ -144,7 +158,8 @@ layout: zh_reference
<span class="red">D</span> hello.rb
</pre>
您可以看到,在简短输出中,有两栏。第一栏是缓存的,第二栏则是工作目录的。所以假设您临时提交了 README 文件,然后又改了些,并且没有执行 <code>git add</code>,您会看到这个:
<p>你可以看到,在简短输出中,有两栏。第一栏是缓存的,第二栏则是工作目录的。
所以假设你临时提交了 README 文件,然后又改了些,并且没有执行 <code>git add</code>,你会看到这个:</p>
<pre>
<b>$ git status -s</b>
@ -153,7 +168,8 @@ layout: zh_reference
</pre>
<p class="nutshell">
<strong>简而言之</strong>,执行 <code>git status</code> 以查看在您上次提交之后有啥被修改或者临时提交了,从而决定自己是否需要提交一次快照,同时也能知道有什么改变被记录进去了。
<strong>一言以蔽之</strong>,执行 <code>git status</code> 以查看在你上次提交之后有啥被修改或者临时提交了,
从而决定自己是否需要提交一次快照,同时也能知道有什么改变被记录进去了。
</p>
</div>
@ -170,7 +186,9 @@ layout: zh_reference
</h2>
<div class="block">
<p><code>git diff</code> 有两个主要的应用场景。我们将在此介绍其一,在 <a href="/inspect">检阅与对照</a> 一章中,我们将介绍其二。我们这里介绍的方式是用此命令描述已临时提交的或者已修改但尚未提交的改动。
<p><code>git diff</code> 有两个主要的应用场景。我们将在此介绍其一,
<a href="/inspect">检阅与对照</a> 一章中,我们将介绍其二。
我们这里介绍的方式是用此命令描述已临时提交的或者已修改但尚未提交的改动。
</p>
<h4>
@ -178,7 +196,7 @@ layout: zh_reference
<small>#尚未缓存的改动</small>
</h4>
<p>如果没有其他参数,<code>git diff</code> 会以规范化的 diff 格式(一个补丁)显示自从上次提交快照之后尚未缓存的所有更改。
<p>如果没有其他参数,<code>git diff</code> 会以规范化的 diff 格式(一个补丁)显示自从上次提交快照之后尚未缓存的所有更改。
</p>
<pre>
@ -192,16 +210,18 @@ index d62ac43..8d15d50 100644
+++ b/hello.rb</span>
<span class="lblue">@@ -1,7 +1,7 @@</span>
class HelloWorld
def self.hello
<span class="red">- puts "hello world"</span>
<span class="green">+ puts "hola mundo"</span>
end
end
</pre>
<p>所以,<code>git status</code>显示您上次提交更新至后所更改或者写入缓存的改动,而 <code>git diff</code> 一行一行地显示这些改动具体是啥。通常执行完 <code>git status</code> 之后接着跑一下 <code>git diff</code> 是个好习惯。
<p>所以,<code>git status</code>显示你上次提交更新至后所更改或者写入缓存的改动,
<code>git diff</code> 一行一行地显示这些改动具体是啥。
通常执行完 <code>git status</code> 之后接着跑一下 <code>git diff</code> 是个好习惯。
</p>
<h4>
@ -209,7 +229,9 @@ index d62ac43..8d15d50 100644
<small>#查看已缓存的改动</small>
</h4>
<p><code>git diff --cached</code> 命令会告诉您有哪些内容已经写入缓存了。也就是说,此命令显示的是接下来要写入快照的内容。所以,如果您将上述示例中的 <code>hello.rb</code> 写入缓存,因为 <code>git diff</code> 显示的是尚未缓存的改动,所以在此执行它不会显示任何信息。
<p><code>git diff --cached</code> 命令会告诉你有哪些内容已经写入缓存了。
也就是说,此命令显示的是接下来要写入快照的内容。所以,如果你将上述示例中的 <code>hello.rb</code>
写入缓存,因为 <code>git diff</code> 显示的是尚未缓存的改动,所以在此执行它不会显示任何信息。
</p>
<pre>
@ -222,7 +244,7 @@ index d62ac43..8d15d50 100644
<b>$ </b>
</pre>
<p>如果您想看看已缓存的改动,您需要执行的是
<p>如果你想看看已缓存的改动,你需要执行的是
<code>git diff --cached</code></p>
<pre>
@ -237,12 +259,12 @@ index d62ac43..8d15d50 100644
+++ b/hello.rb</span>
<span class="lblue">@@ -1,7 +1,7 @@</span>
class HelloWorld
def self.hello
<span class="red">- puts "hello world"</span>
<span class="green">+ puts "hola mundo"</span>
end
end
</pre>
@ -251,7 +273,10 @@ index d62ac43..8d15d50 100644
<small>查看已缓存的与未缓存的所有改动</small>
</h4>
<p>如果您想一并查看已缓存的与未缓存的改动,可以执行 <code>git diff HEAD</code> ——也就是说您要看到的是工作目录与上一次提交的更新的区别,无视缓存。假设我们又改了些 <code>ruby.rb</code> 的内容,那缓存的与未缓存的改动我们就都有了。以上三个 <code>diff</code> 命令的结果如下:
<p>如果你想一并查看已缓存的与未缓存的改动,可以执行 <code>git diff HEAD</code> ——
也就是说你要看到的是工作目录与上一次提交的更新的区别,无视缓存。
假设我们又改了些 <code>ruby.rb</code> 的内容,那缓存的与未缓存的改动我们就都有了。
以上三个 <code>diff</code> 命令的结果如下:
</p>
<pre>
<b>$ vim hello.rb </b>
@ -262,12 +287,12 @@ index 4f40006..2ae9ba4 100644
+++ b/hello.rb</span>
<span class="lblue">@@ -1,7 +1,7 @@</span>
class HelloWorld
<span class="green">+ # says hello</span>
def self.hello
puts "hola mundo"
end
end
<b>$ git diff --cached</b>
<span class="umber">diff --git a/hello.rb b/hello.rb
@ -276,12 +301,12 @@ index 2aabb6e..4f40006 100644
+++ b/hello.rb</span>
<span class="lblue">@@ -1,7 +1,7 @@</span>
class HelloWorld
def self.hello
<span class="red">- puts "hello world"</span>
<span class="green">+ puts "hola mundo"</span>
end
end
<b>$ git diff HEAD</b>
<span class="umber">diff --git a/hello.rb b/hello.rb
@ -290,13 +315,13 @@ index 2aabb6e..2ae9ba4 100644
+++ b/hello.rb</span>
<span class="lblue">@@ -1,7 +1,8 @@</span>
class HelloWorld
<span class="green">+ # says hello</span>
def self.hello
<span class="red">- puts "hello world"</span>
<span class="green">+ puts "hola mundo"</span>
end
end
</pre>
@ -305,9 +330,10 @@ index 2aabb6e..2ae9ba4 100644
<small>显示摘要而非整个 diff</small>
</h4>
<p>如果我们不想要看整个 diff 输出,但是又想比 <code>git status</code> 详细点,就可以用 <code>--stat</code> 选项。该选项使它显示摘要而非全文。上文示例在使用 <code>--stat</code> 选项时,输出如下:
<p>如果我们不想要看整个 diff 输出,但是又想比 <code>git status</code> 详细点,
就可以用 <code>--stat</code> 选项。该选项使它显示摘要而非全文。上文示例在使用 <code>--stat</code> 选项时,输出如下:
</p>
<pre>
<b>$ git status -s</b>
<span class="green">M</span><span class="red">M</span> hello.rb
@ -322,13 +348,14 @@ index 2aabb6e..2ae9ba4 100644
1 files changed, 2 insertions(+), 1 deletions(-)
</pre>
<p>还可以在上述命令后面制定一个目录,从而只查看特定文件或子目录的 <code>diff</code> 输出。
<p>还可以在上述命令后面制定一个目录,从而只查看特定文件或子目录的 <code>diff</code> 输出。
</p>
<p class="nutshell">
<strong>简而言之</strong>
执行 <code>git diff</code> 来查看执行 <code>git status</code> 的结果的详细信息 —— 一行一行地显示这些文件是如何被修改或写入缓存的。
<strong>简而言之</strong>
执行 <code>git diff</code> 来查看执行 <code>git status</code> 的结果的详细信息 ——
一行一行地显示这些文件是如何被修改或写入缓存的。
</p>
</div>
@ -346,7 +373,9 @@ index 2aabb6e..2ae9ba4 100644
<div class="block">
<p>现在您使用 <code>git add</code> 命令将想要快照的内容写入了缓存,执行 <code> git commit</code> 就将它实际存储快照了。Git 为您的每一个提交都记录您的名字与电子邮箱地址,所以第一步是告诉 Git 这些都是啥。
<p>现在你使用 <code>git add</code> 命令将想要快照的内容写入了缓存,
执行 <code> git commit</code> 就将它实际存储快照了。
Git 为你的每一个提交都记录你的名字与电子邮箱地址,所以第一步是告诉 Git 这些都是啥。
</p>
<pre>
@ -354,7 +383,7 @@ index 2aabb6e..2ae9ba4 100644
<b>$ git config --global user.email you@somedomain.com</b>
</pre>
<p>让我们写入缓存,并提交对 <code>hello.rb</code> 的所有改动。在首个例子中,我们使用 <code>-m</code> 选项以在命令行中提供提交注释。
<p>让我们写入缓存,并提交对 <code>hello.rb</code> 的所有改动。在首个例子中,我们使用 <code>-m</code> 选项以在命令行中提供提交注释。
</p>
<pre>
@ -366,7 +395,8 @@ index 2aabb6e..2ae9ba4 100644
1 files changed, 2 insertions(+), 1 deletions(-)
</pre>
<p>现在我们已经记录了快照。如果我们再执行 <code>git status</code>,会看到我们有一个“干净的工作目录”。这意味着我们在最近一次提交之后,没有做任何改动 —— 在我们的项目中没有未快照的工作。
<p>现在我们已经记录了快照。如果我们再执行 <code>git status</code>,会看到我们有一个“干净的工作目录”。
这意味着我们在最近一次提交之后,没有做任何改动 —— 在我们的项目中没有未快照的工作。
</p>
<pre>
@ -375,7 +405,8 @@ index 2aabb6e..2ae9ba4 100644
nothing to commit (working directory clean)
</pre>
<p>如果您漏掉了 <code>-m</code> 选项Git 会尝试为您打开一个编辑器以填写提交信息。如果 Git 在您对它的配置中找不到相关信息,默认会打开 <code>vim</code>。屏幕会像这样:
<p>如果你漏掉了 <code>-m</code> 选项Git 会尝试为你打开一个编辑器以填写提交信息。
如果 Git 在你对它的配置中找不到相关信息,默认会打开 <code>vim</code>。屏幕会像这样:
</p>
<pre>
@ -393,12 +424,12 @@ nothing to commit (working directory clean)
".git/COMMIT_EDITMSG" 9L, 257C
</pre>
<p>在此,您在文件头部添加实际的提交信息。以“#”开头的行都会被无视 ——Git 将 <code> git status</code> 的输出结果放在那儿以提示都改了、缓存了啥。
<p>在此,你在文件头部添加实际的提交信息。以“#”开头的行都会被无视 ——Git 将 <code> git status</code> 的输出结果放在那儿以提示都改了、缓存了啥。
</p>
<p>通常,撰写良好的提交信息是很重要的。以开放源代码项目为例,多多少少以以下格式写的提示消息是个不成文的规定:
<p>通常,撰写良好的提交信息是很重要的。以开放源代码项目为例,多多少少以以下格式写的提示消息是个不成文的规定:
</p>
<pre>
简短的关于改动的总结25个字或者更少
@ -429,7 +460,10 @@ nothing to commit (working directory clean)
</pre>
<p class="aside">
提交注解是很重要的。因为 Git 很大一部分能耐就是它在组织本地提交和与他人分享的弹性,它很给力地能够让您为逻辑独立的改变写三到四条提交注解,以便您的工作被同仁审阅。因为提交与推送改动是有区别的,请务必花时间将各个逻辑独立的改动放到另外一个提交,并附上一份良好的提交注解,以使与您合作的人能够方便地了解您所做的,以及您为何要这么做。
提交注解是很重要的。因为 Git 很大一部分能耐就是它在组织本地提交和与他人分享的弹性,
它很给力地能够让你为逻辑独立的改变写三到四条提交注解,以便你的工作被同仁审阅。因为提交与推送改动是有区别的,
请务必花时间将各个逻辑独立的改动放到另外一个提交,并附上一份良好的提交注解,
以使与你合作的人能够方便地了解你所做的,以及你为何要这么做。
</p>
<h4>
@ -437,7 +471,11 @@ nothing to commit (working directory clean)
<small>自动将在提交前将已记录、修改的文件放入缓存区</small>
</h4>
<p>如果您觉得 <code>git add</code> 提交缓存的流程太过繁琐Git 也允许您用 <code>-a</code> 选项跳过这一步。基本上这句话的意思就是,为任何已有记录的文件执行 <code>git add</code> —— 也就是说,任何在您最近的提交中已经存在,并且之后被修改的文件。这让您能够用更 Subversion 方式的流程,修改些文件,然后想要快照所有所做的改动的时候执行 <code>git commit -a</code>。不过您仍然需要执行 <code>git add</code> 来添加新文件,就像 Subversion 一样。
<p>如果你觉得 <code>git add</code> 提交缓存的流程太过繁琐Git 也允许你用 <code>-a</code> 选项跳过这一步。
基本上这句话的意思就是,为任何已有记录的文件执行 <code>git add</code> ——
也就是说,任何在你最近的提交中已经存在,并且之后被修改的文件。
这让你能够用更 Subversion 方式的流程,修改些文件,然后想要快照所有所做的改动的时候执行 <code>git commit -a</code>
不过你仍然需要执行 <code>git add</code> 来添加新文件,就像 Subversion 一样。
</p>
<pre>
@ -458,15 +496,18 @@ nothing to commit (working directory clean)
1 files changed, 2 insertions(+), 1 deletions(-)
</pre>
<p>注意,如果您不缓存改动,直接执行 <code>git commit</code>Git 会直接给出 <code>git status</code> 命令的输出,提醒您啥也没缓存。我已将该消息中的重要部分高亮,它说没有添加需要提交的缓存。如果您使用 <code>-a</code>,它会缓存并提交每个改动(不含新文件)。
<p>注意,如果你不缓存改动,直接执行 <code>git commit</code>Git 会直接给出 <code>git status</code>
命令的输出,提醒你啥也没缓存。我已将该消息中的重要部分高亮,它说没有添加需要提交的缓存。
如果你使用 <code>-a</code>,它会缓存并提交每个改动(不含新文件)。
</p>
<p>
现在您就完成了整个快照的流程 ——改些文件,然后用 <code>git add</code> 将要提交的改动提交到缓存,用 <code>git status</code><code>git diff</code> 看看您都改了啥,最后 <code>git commit</code> 永久地保存快照。
</p>
<p>
现在你就完成了整个快照的流程 ——改些文件,然后用 <code>git add</code> 将要提交的改动提交到缓存,
<code>git status</code><code>git diff</code> 看看你都改了啥,最后 <code>git commit</code> 永久地保存快照。
</p>
<p class="nutshell">
<strong>简而言之</strong>,执行 <code>git commit</code> 记录缓存区的快照。如果需要的话,这个快照可以用来做比较、共享以及恢复。
<strong>简而言之</strong>,执行 <code>git commit</code> 记录缓存区的快照。如果需要的话,这个快照可以用来做比较、共享以及恢复。
</p>
</div>
@ -483,14 +524,19 @@ nothing to commit (working directory clean)
</h2>
<div class="block">
<p><code>git reset</code> 可能是人类写的最费解的命令了。我用 Git 有些年头了,甚至还写了本书,但有的时候还是会搞不清它会做什么。所以,我只说三个明确的,通常有用的调用。请您跟我一样尽管用它 —— 因为它可以很有用。
<p><code>git reset</code> 可能是人类写的最费解的命令了。
我用 Git 有些年头了,甚至还写了本书,但有的时候还是会搞不清它会做什么。
所以,我只说三个明确的,通常有用的调用。请你跟我一样尽管用它 —— 因为它可以很有用。
</p>
<p>在此例中,我们可以用它来将不小心缓存的东东取消缓存。假设您修改了两个文件,想要将它们记录到两个不同的提交中去。您应该缓存并提交一个,再缓存并提交另外一个。如果您不小心两个都缓存了,那要如何才能<i>取消</i>缓存呢?您可以用 <code>git reset HEAD -- file</code>。技术上说,在这里您不需要使用 <code>--</code> —— 它用来告诉 Git 这时您已经不再列选项,剩下的是文件路径了。不过养成使用它分隔选项与路径的习惯很重要,即使在您可能并不需要的时候。
<p>在此例中,我们可以用它来将不小心缓存的东东取消缓存。假设你修改了两个文件,想要将它们记录到两个不同的提交中去。
你应该缓存并提交一个,再缓存并提交另外一个。如果你不小心两个都缓存了,那要如何才能<i>取消</i>缓存呢?
你可以用 <code>git reset HEAD -- file</code>
技术上说,在这里你不需要使用 <code>--</code> —— 它用来告诉 Git 这时你已经不再列选项,剩下的是文件路径了。
不过养成使用它分隔选项与路径的习惯很重要,即使在你可能并不需要的时候。
</p>
<p>好,让我们看看取消缓存是什么样子的。这里我们有两个最近提交之后又有所改动的文件。我们将两个都缓存,并取消缓存其中一个。
</p>
<p>好,让我们看看取消缓存是什么样子的。这里我们有两个最近提交之后又有所改动的文件。我们将两个都缓存,并取消缓存其中一个。</p>
<pre>
<b>$ git status -s</b>
@ -508,19 +554,24 @@ M hello.rb
<span class="red">M</span> hello.rb
</pre>
<p>
现在您执行 <code>git commit</code> 将只记录 <code>README</code> 文件的改动,并不含现在并不在缓存中的 <code>hello.rb</code>
<p>
现在你执行 <code>git commit</code> 将只记录 <code>README</code> 文件的改动,并不含现在并不在缓存中的 <code>hello.rb</code>
</p>
<p class="aside">
如果您好奇,它实际的操作是将该文件在“索引”中的校验和重置为最近一次提交中的值。<code>git add</code> 会计算一个文件的校验和,将它添加到“索引”中,而 <code>git reset HEAD</code> 将它改写回原先的,从而取消缓存操作。
如果你好奇,它实际的操作是将该文件在“索引”中的校验和重置为最近一次提交中的值。
<code>git add</code> 会计算一个文件的校验和,将它添加到“索引”中,
<code>git reset HEAD</code> 将它改写回原先的,从而取消缓存操作。
</p>
<p class="tip">
如果您想直接执行 <code>git unstage</code>,您可以在 Git 中配置个别名。执行 <code>git config --global alias.unstage "reset HEAD"</code> 即可。一旦执行完它,您就可以直接用 <code>git unstage [file]</code> 作为代替了。
如果你想直接执行 <code>git unstage</code>,你可以在 Git 中配置个别名。
执行 <code>git config --global alias.unstage "reset HEAD"</code> 即可。
一旦执行完它,你就可以直接用 <code>git unstage [file]</code> 作为代替了。
</p>
<p>如果您忘了取消缓存的命令Git 的常规 <code>git status</code> 输出的提示会很有帮助。例如,在您有已缓存的文件时,如果您不带 <code>-s</code> 执行 <code>git status</code>,它将告诉您怎样取消缓存:
<p>如果你忘了取消缓存的命令Git 的常规 <code>git status</code> 输出的提示会很有帮助。
例如,在你有已缓存的文件时,如果你不带 <code>-s</code> 执行 <code>git status</code>,它将告诉你怎样取消缓存:
</p>
<pre>
@ -535,7 +586,7 @@ M hello.rb
</pre>
<p class="nutshell">
<strong>简而言之</strong>,执行 <code>git reset HEAD</code> 以取消之前 <code>git add</code> 添加,但不希望包含在下一提交快照中的缓存。
<strong>简而言之</strong>,执行 <code>git reset HEAD</code> 以取消之前 <code>git add</code> 添加,但不希望包含在下一提交快照中的缓存。
</p>
</div>
@ -553,30 +604,38 @@ M hello.rb
<div class="block">
<p>
<code>git rm</code> 会将条目从缓存区中移除。这与 <code>git reset HEAD</code> 将条目取消缓存是有区别的。“取消缓存”的意思就是将缓存区恢复为我们做出修改之前的样子。在另一方面,<code>git rm</code> 则将该文件彻底从缓存区踢出,因此它不再下一个提交快照之内,进而有效地删除它。
</p>
<p>
<code>git rm</code> 会将条目从缓存区中移除。这与 <code>git reset HEAD</code> 将条目取消缓存是有区别的。
“取消缓存”的意思就是将缓存区恢复为我们做出修改之前的样子。
在另一方面,<code>git rm</code> 则将该文件彻底从缓存区踢出,因此它不再下一个提交快照之内,进而有效地删除它。
</p>
<p>
默认情况下,<code>git rm file</code> 会将文件从缓存区和您的硬盘中(工作目录)删除。如果要在工作目录中留着该文件,可以使用 <code>git rm --cached</code>
<p>
默认情况下,<code>git rm file</code> 会将文件从缓存区和你的硬盘中(工作目录)删除。
如果要在工作目录中留着该文件,可以使用 <code>git rm --cached</code>
</p>
<h4>
git mv
<small>git rm --cached orig; mv orig new; git add new</small>
</h4>
<p>
不像绝大多数其他版本控制系统Git 并不记录记录文件重命名。它反而只记录快照并对比快照以找到有啥文件可能被重命名了。如果一个文件从更新中删除了而在下次快照中新添加的另一个文件的内容与它很相似Git 就知道这极有可能是个重命名。因此,虽然有 <code>git mv</code> 命令,但它有点多余 —— 它做得所有事情就是 <code>git rm --cached</code>,重命名磁盘上的文件,然后再执行 <code>git add</code> 把新文件添加到缓存区。您并不需要用它,不过如果觉得这样容易些,尽管用吧。
不像绝大多数其他版本控制系统Git 并不记录记录文件重命名。它反而只记录快照,并对比快照以找到有啥文件可能被重命名了。
如果一个文件从更新中删除了而在下次快照中新添加的另一个文件的内容与它很相似Git 就知道这极有可能是个重命名。
因此,虽然有 <code>git mv</code> 命令,但它有点多余 —— 它做得所有事情就是 <code>git rm --cached</code>
重命名磁盘上的文件,然后再执行 <code>git add</code> 把新文件添加到缓存区。
你并不需要用它,不过如果觉得这样容易些,尽管用吧。
</p>
<p class="aside">
我自己并不使用此命令的普通形式 —— 删除文件。通常直接从硬盘删除文件,然后执行 <code>git commit -a</code> 会简单些。它会自动将删除的文件从索引中移除。
我自己并不使用此命令的普通形式 —— 删除文件。通常直接从硬盘删除文件,然后执行 <code>git commit -a</code> 会简单些。
它会自动将删除的文件从索引中移除。
</p>
<p class="nutshell">
<strong>简而言之</strong>
执行 <code>git rm</code> 来删除 Git 追踪的文件。它还会删除的工作目录中的相应文件。
执行 <code>git rm</code> 来删除 Git 追踪的文件。它还会删除的工作目录中的相应文件。
</p>
</div>

@ -10,11 +10,17 @@ layout: zh_reference
分支与合并
</h2>
<div class="block">
<p>分支是我最喜欢的 Git 特性之一。如果您用过其他版本控制系统,把您所知的分支给忘记,倒可能更有帮助些 —— 事实上,以我们使用分支的方式,把 Git 的分支看作 <i>上下文</i> 反而更合适。当您检出分支时,您可以在两三个不同的分支之间来回切换。
<p>分支是我最喜欢的 Git 特性之一。如果你用过其他版本控制系统,把你所知的分支给忘记,倒可能更有帮助些 ——
事实上,以我们使用分支的方式,把 Git 的分支看作 <i>上下文</i> 反而更合适。
当你检出分支时,你可以在两三个不同的分支之间来回切换。
</p>
<p class="nutshell">
<b>简而言之</b>,您可以执行 <code>git branch (branchname)</code> 来创建分支,使用 <code>git checkout (branchname)</code> 命令切换到该分支在该分支的上下文环境中提交快照等之后可以很容易地来回切换。当您切换分支的时候Git 会用该分支的最后提交的快照替换您的工作目录的内容,所以多个分支不需要多个目录。使用 <code>git merge</code> 来合并分支。您可以多次合并到统一分支,也可以选择在合并之后直接删除被并入的分支。
<b>简而言之</b>,你可以执行 <code>git branch (branchname)</code> 来创建分支,
使用 <code>git checkout (branchname)</code> 命令切换到该分支,在该分支的上下文环境中,
提交快照等之后可以很容易地来回切换。当你切换分支的时候Git 会用该分支的最后提交的快照替换你的工作目录的内容,
所以多个分支不需要多个目录。使用 <code>git merge</code> 来合并分支。你可以多次合并到统一分支,
也可以选择在合并之后直接删除被并入的分支。
</p>
</div>
@ -42,7 +48,9 @@ layout: zh_reference
</h2>
<div class="block">
<p><code>git branch</code> 命令是 Git 中的通用分支管理工具,可以通过它完成多项任务。我们先说您会用到的最多的命令 —— 列出分支、创建分支和删除分支。我们还会介绍用来切换分支的 <code>git checkout</code> 命令。
<p><code>git branch</code> 命令是 Git 中的通用分支管理工具,可以通过它完成多项任务。
我们先说你会用到的最多的命令 —— 列出分支、创建分支和删除分支。
我们还会介绍用来切换分支的 <code>git checkout</code> 命令。
</p>
<h4>
@ -50,7 +58,8 @@ layout: zh_reference
<small>列出可用的分支</small>
</h4>
<p>没有参数是,<code>git branch</code> 会列出您在本地的分支。您当前所在的分支的行首会有个星号作标记。如果您开启了<a href="http://progit.org/book/ch7-1.html#colors_in_git">彩色模式</a>,当前分支会用绿色显示。
<p>没有参数时,<code>git branch</code> 会列出你在本地的分支。你所在的分支的行首会有个星号作标记。
如果你开启了<a href="http://progit.org/book/ch7-1.html#colors_in_git">彩色模式</a>,当前分支会用绿色显示。
</p>
<pre>
@ -58,7 +67,10 @@ $ git branch
* <span class="green">master</span>
</pre>
<p>此例的意思就是我们有一个叫做“master”的分支并且该分支是当前分支。当您执行 <code>git init</code> 的时候,缺省情况下 Git 就会为您创建“master”分支。但是这名字一点特殊意味都没有 —— 事实上您并不非得要一个叫做“master”的分支。不过由于它是缺省分支名的缘故绝大部分项目都有这个分支。
<p>此例的意思就是我们有一个叫做“master”的分支并且该分支是当前分支。
当你执行 <code>git init</code> 的时候,缺省情况下 Git 就会为你创建“master”分支。
但是这名字一点特殊意味都没有 —— 事实上你并不非得要一个叫做“master”的分支。
不过由于它是缺省分支名的缘故,绝大部分项目都有这个分支。
</p>
<h4>
@ -66,7 +78,7 @@ $ git branch
<small>创建新分支</small>
</h4>
<p>我们动手创建一个分支,并切换过去。执行 <code>git branch (branchname)</code> 即可。
<p>我们动手创建一个分支,并切换过去。执行 <code>git branch (branchname)</code> 即可。
<pre>
$ git branch testing
@ -75,7 +87,10 @@ $ git branch
testing
</pre>
<p>现在我们可以看到有了一个新分支。当您以此方式在上次提交更新之后创建了新分支如果后来又有更新提交然后又切换到了“testing”分支Git 将还原您的工作目录到您创建分支时候的样子 —— 您可以把它看作一个记录您当前进度的书签。让我们实际运用看看 —— 我们用 <code>git checkout (branch)</code> 切换到我们要修改的分支。
<p>现在我们可以看到,有了一个新分支。当你以此方式在上次提交更新之后创建了新分支,如果后来又有更新提交,
然后又切换到了“testing”分支Git 将还原你的工作目录到你创建分支时候的样子 ——
你可以把它看作一个记录你当前进度的书签。让我们实际运用看看 ——
我们用 <code>git checkout (branch)</code> 切换到我们要修改的分支。
</p>
<pre>
@ -115,7 +130,10 @@ README hello.rb more.txt test.txt
</h4>
<p>
通常情况下您会更希望立即切换到新分支从而在该分支中操作然后当此分支的开发日趋稳定时将它合并到稳定版本的分支例如“master”中去。执行 <code>git branch newbranch; git checkout newbranch</code> 也很简单,不过 Git 还为您提供了快捷方式:<code>git checkout -b newbranch</code>
通常情况下,你会更希望立即切换到新分支,从而在该分支中操作,然后当此分支的开发日趋稳定时,
将它合并到稳定版本的分支例如“master”中去。
执行 <code>git branch newbranch; git checkout newbranch</code> 也很简单,
不过 Git 还为你提供了快捷方式:<code>git checkout -b newbranch</code>
</p>
<pre>
@ -142,11 +160,14 @@ Switched to branch 'master'
README hello.rb more.txt test.txt
</pre>
<p>如您所见,我们创建了一个分支,在该分支的上下文中移除了一些文件,然后切换回我们的主分支,那些文件又回来了。使用分支将工作切分开来,从而让我们能够在不同上下文中做事,并来回切换。
<p>如你所见,我们创建了一个分支,在该分支的上下文中移除了一些文件,然后切换回我们的主分支,那些文件又回来了。
使用分支将工作切分开来,从而让我们能够在不同上下文中做事,并来回切换。
</p>
<p>
创建新分支,在其中完成一部分工作,完成之后将它合并到主分支并删除。您会觉得这很方便,因为这么做很快很容易。如此,当您觉得这部分工作并不靠谱,舍弃它很容易。并且,如果您必须回到稳定分支做些事情,也可以很方便地这个独立分支的工作先丢在一边,完成要事之后再切换回来。
创建新分支,在其中完成一部分工作,完成之后将它合并到主分支并删除。你会觉得这很方便,因为这么做很快很容易。
如此,当你觉得这部分工作并不靠谱,舍弃它很容易。并且,如果你必须回到稳定分支做些事情,
也可以很方便地这个独立分支的工作先丢在一边,完成要事之后再切换回来。
</p>
<h4>
@ -154,7 +175,9 @@ README hello.rb more.txt test.txt
<small>删除分支</small>
</h4>
<p>假设我们要删除一个分支比如上例中的“testing”分支该分支没啥特殊的内容了可以执行 <code>git branch -d (branch)</code> 把它删掉。
<p>假设我们要删除一个分支比如上例中的“testing”分支该分支没啥特殊的内容了
可以执行 <code>git branch -d (branch)</code> 把它删掉。
</p>
<pre>
<b>$ git branch</b>
@ -167,7 +190,7 @@ Deleted branch testing (was 78b2670).
</pre>
<p class="nutshell">
<b>简而言之</b> 使用 <code>git branch</code> 列出现有的分支、创建新分支以及删除不必要或者已合并的分支。
<b>简而言之</b> 使用 <code>git branch</code> 列出现有的分支、创建新分支以及删除不必要或者已合并的分支。
</p>
</div>
@ -180,11 +203,15 @@ Deleted branch testing (was 78b2670).
<a target="new" href="http://progit.org/book/ch3-2.html#basic_merging">book</a>
</span>
<a name="merge">git merge</a>
<span class="desc">将分支合并到的当前分支</span>
<span class="desc">将分支合并到的当前分支</span>
</h2>
<div class="block">
<p>一旦某分支有了独立内容,您终究会希望将它合并回到您的主分支。您可以使用 <code>git merge</code> 命令将任何分支合并到当前分支中去。我们那上例中的“removals”分支为例。假设我们创建了一个分支移除了一些文件并将它提交到该分支其实该分支是与我们的主分支也就是“master”独立开来的。要想将这些移除操作包含在主分支中您可以将“removals”分支合并回去。
<p>一旦某分支有了独立内容,你终究会希望将它合并回到你的主分支。
你可以使用 <code>git merge</code> 命令将任何分支合并到当前分支中去。
我们那上例中的“removals”分支为例。假设我们创建了一个分支移除了一些文件并将它提交到该分支
其实该分支是与我们的主分支也就是“master”独立开来的。
要想将这些移除操作包含在主分支中你可以将“removals”分支合并回去。
</p>
<pre>
@ -209,7 +236,9 @@ Fast-forward
更多复杂合并
</h4>
<p>当然合并并不仅仅是简单的文件添加、移除的操作Git 也会合并修改 —— 事实上,它很会合并修改。举例,我们看看在某分支中编辑某个文件,然后在另一个分支中把它的名字改掉再做些修改,最后将这俩分支合并起来。您觉得会变成一坨 shi我们试试看。
<p>当然合并并不仅仅是简单的文件添加、移除的操作Git 也会合并修改 —— 事实上,它很会合并修改。
举例,我们看看在某分支中编辑某个文件,然后在另一个分支中把它的名字改掉再做些修改,
最后将这俩分支合并起来。你觉得会变成一坨 shi我们试试看。
</p>
<pre>
@ -225,7 +254,7 @@ end
HelloWorld.hello
</pre>
<p>首先我们创建一个叫做“change_class”的分支切换过去从而将重命名类等操作独立出来。我们将类名从 “HelloWorld” 改为 “HiWorld”。
<p>首先我们创建一个叫做“change_class”的分支切换过去从而将重命名类等操作独立出来。我们将类名从 “HelloWorld” 改为 “HiWorld”。
</p>
<pre>
@ -240,7 +269,10 @@ class HiWorld
1 files changed, 2 insertions(+), 4 deletions(-)
</pre>
<p>然后,将重命名类操作提交到 “change_class” 分支中。现在,假如切换回 “master” 分支我们可以看到类名恢复到了我们切换到 “change_class” 分支之前的样子。现在,再做些修改(即代码中的输出),同时将文件名从 <code>hello.rb</code> 改为 <code>ruby.rb</code>
<p>然后,将重命名类操作提交到 “change_class” 分支中。
现在,假如切换回 “master” 分支我们可以看到类名恢复到了我们切换到 “change_class” 分支之前的样子。
现在,再做些修改(即代码中的输出),同时将文件名从 <code>hello.rb</code> 改为 <code>ruby.rb</code>
</p>
<pre>
<b>$ git checkout master</b>
@ -267,8 +299,10 @@ index 2aabb6e..bf64b17 100644
rename hello.rb => ruby.rb (65%)
</pre>
<p>现在这些改变已经记录到我的 “master” 分支了。请注意,这里类名还是 “HelloWorld”而不是 “HiWorld”。然后我想将类名的改变合并过来我把 “change_class” 分支合并过来就行了。但是我已经将文件名都改掉了Git 知道该怎么办么?
</p>
<p>现在这些改变已经记录到我的 “master” 分支了。请注意,这里类名还是 “HelloWorld”而不是 “HiWorld”。
然后我想将类名的改变合并过来,我把 “change_class” 分支合并过来就行了。
但是我已经将文件名都改掉了Git 知道该怎么办么?
</p>
<pre>
<b>$ git branch</b>
@ -297,7 +331,9 @@ HiWorld.hello
合并冲突
</h4>
<p>那么Git 合并很有魔力,我们再也不用处理合并冲突了,对吗?不太确切。不同分支中修改了相同区块的代码,电脑自己猜不透神马的情况下,冲突就摆在我们面前了。我们看看两个分支中改了同一行代码的例子。
<p>那么Git 合并很有魔力,我们再也不用处理合并冲突了,对吗?不太确切。
不同分支中修改了相同区块的代码,电脑自己猜不透神马的情况下,冲突就摆在我们面前了。
我们看看两个分支中改了同一行代码的例子。
<p>
<pre>
@ -311,7 +347,7 @@ Switched to a new branch 'fix_readme'
1 files changed, 1 insertions(+), 1 deletions(-)
</pre>
<p>我们在某分支中修改了 README 文件中的一行,并提交了。我们再在 “master” 分支中对同个文件的同一行内容作不同的修改。
<p>我们在某分支中修改了 README 文件中的一行,并提交了。我们再在 “master” 分支中对同个文件的同一行内容作不同的修改。
</p>
<pre>
@ -342,7 +378,10 @@ This project has examples of hello world in
nearly every programming language.
</pre>
<p>您可以看到Git 在产生合并冲突的地方插入了标准的与 Subversion 很像的合并冲突标记。轮到我们去解决这些冲突了。在这里我们就手动把它解决。如果您要 Git 打开一个图形化的合并工具,可以看看 <a href="http://www.kernel.org/pub/software/scm/git/docs/git-mergetool.html">git 合并工具</a>(比如 kdiff3、emerge、p4merge 等)。
<p>你可以看到Git 在产生合并冲突的地方插入了标准的与 Subversion 很像的合并冲突标记。
轮到我们去解决这些冲突了。在这里我们就手动把它解决。如果你要 Git 打开一个图形化的合并工具,
可以看看 <a href="http://www.kernel.org/pub/software/scm/git/docs/git-mergetool.html">git 合并工具</a>
(比如 kdiff3、emerge、p4merge 等)。
</p>
<pre>
@ -360,7 +399,9 @@ index 9103e27,69cad1a..0000000
This project has examples of hello world in
</pre>
<p>在 Git 中,处理合并冲突的时候有个很酷的提示。如果您执行 <code>git diff</code>,就像我演示的这样,它会告诉您冲突的两方,和您是如何解决的。现在是时候把它标记为已解决了。在 Git 中,我们可以用 <code>git add</code> —— 要告诉 Git 文件冲突已经解决,您必须把它写入缓存区。
<p>在 Git 中,处理合并冲突的时候有个很酷的提示。
如果你执行 <code>git diff</code>,就像我演示的这样,它会告诉你冲突的两方,和你是如何解决的。
现在是时候把它标记为已解决了。在 Git 中,我们可以用 <code>git add</code> —— 要告诉 Git 文件冲突已经解决,你必须把它写入缓存区。
</p>
<pre>
@ -377,7 +418,8 @@ M README
</p>
<p class="nutshell">
<b>简而言之</b> 使用 <code>git merge</code> 将另一个分支并入当前的分支中去。Git 会自动以最佳方式将两个不同快照中独特的工作合并到一个新快照中去。
<b>简而言之</b> 使用 <code>git merge</code> 将另一个分支并入当前的分支中去。
Git 会自动以最佳方式将两个不同快照中独特的工作合并到一个新快照中去。
</p>
</div>
@ -395,15 +437,21 @@ M README
<div class="block">
<p>
到目前为止我们已经提交快照到项目中在不同的各自分离的上下文中切换但假如我们忘了自己是如何到目前这一步的那该怎么办或者假如我们想知道此分支与彼分支到底有啥区别Git 提供了一个告诉您使您达成当前快照的所有提交消息的工具,叫做 <code>git log</code>
<p>到目前为止,我们已经提交快照到项目中,在不同的各自分离的上下文中切换,
但假如我们忘了自己是如何到目前这一步的那该怎么办?或者假如我们想知道此分支与彼分支到底有啥区别?
Git 提供了一个告诉你使你达成当前快照的所有提交消息的工具,叫做 <code>git log</code>
</p>
<p>
要理解日志log命令您需要了解当执行 <code>git commit</code> 以存储一个快照的时候都有啥信息被保存了。除了文件详单、提交消息和提交者的信息Git 还保存了您的此次提交所基于的快照。也就是,假如您克隆了一个项目,您是在什么快照的基础上做的修改而得到新保存的快照的?这有益于为项目进程提供上下文,使 Git 能够弄明白谁做了什么改动。如果 Git 有您的快照所基于的快照的话,它就能自动判断您都改变了什么。而新提交所基于的提交,被称作新提交的“父亲”。
<p>要理解日志log命令你需要了解当执行 <code>git commit</code> 以存储一个快照的时候,都有啥信息被保存了。
除了文件详单、提交消息和提交者的信息Git 还保存了你的此次提交所基于的快照。
也就是,假如你克隆了一个项目,你是在什么快照的基础上做的修改而得到新保存的快照的?
这有益于为项目进程提供上下文,使 Git 能够弄明白谁做了什么改动。
如果 Git 有你的快照所基于的快照的话,它就能自动判断你都改变了什么。而新提交所基于的提交,被称作新提交的“父亲”。
</p>
<p>某分支的按时间排序的“父亲”列表,当您在该分支时,可以执行 <code>git log</code> 以查看。例如,如果我们在本章中操作的 Hello World 项目中执行 <code>git log</code>,我们可以看到已提交的消息。
<p>某分支的按时间排序的“父亲”列表,当你在该分支时,可以执行 <code>git log</code> 以查看。
例如,如果我们在本章中操作的 Hello World 项目中执行 <code>git log</code>,我们可以看到已提交的消息。
</p>
<pre>
<b>$ git log</b>
@ -438,7 +486,7 @@ Date: Fri Jun 4 12:37:05 2010 +0200
...
</pre>
<p>我们可以用 <code>--oneline</code> 选项来查看历史记录的紧凑简洁的版本。
<p>我们可以用 <code>--oneline</code> 选项来查看历史记录的紧凑简洁的版本。
</p>
<pre>
@ -452,11 +500,11 @@ b7ae93b added from ruby
17f4acf first commit
</pre>
<p>
这告诉我们的是,此项目的开发历史。如果提交消息描述性很好,这就能为我们提供关于有啥改动被应用、或者影响了当前快照的状态、以及这快照里头都有啥。
<p>
这告诉我们的是,此项目的开发历史。如果提交消息描述性很好,这就能为我们提供关于有啥改动被应用、或者影响了当前快照的状态、以及这快照里头都有啥。
</p>
<p>我们还可以用它的十分有帮助的 <code>--graph</code> 选项,查看历史中什么时候出现了分支、合并。以下为相同的命令,开启了拓扑图选项:
<p>我们还可以用它的十分有帮助的 <code>--graph</code> 选项,查看历史中什么时候出现了分支、合并。以下为相同的命令,开启了拓扑图选项:
</p>
<pre>
@ -474,10 +522,15 @@ b7ae93b added from ruby
* 17f4acf first commit
</pre>
<p>现在我们可以更清楚明了地看到何时工作分叉、又何时归并。这对查看发生了什么、应用了什么改变很有帮助,并且极大地帮助您管理您的分支。让我们创建一个分支,在里头做些事情,然后切回到主分支,也做点事情,然后看看 <code>log</code> 命令是如何帮助我们理清这俩分支上都发生了啥的。
<p>现在我们可以更清楚明了地看到何时工作分叉、又何时归并。
这对查看发生了什么、应用了什么改变很有帮助,并且极大地帮助你管理你的分支。
让我们创建一个分支,在里头做些事情,然后切回到主分支,也做点事情,然后看看 <code>log</code>
命令是如何帮助我们理清这俩分支上都发生了啥的。
</p>
<p>首先我们创建一个分支,来添加 Erlang 编程语言的 Hello World 示例 —— 我们想要在一个分支里头做这个,以避免让可能还不能工作的代码弄乱我们的稳定分支。这样就可以切来切去,片叶不沾身。
<p>首先我们创建一个分支,来添加 Erlang 编程语言的 Hello World 示例 ——
我们想要在一个分支里头做这个,以避免让可能还不能工作的代码弄乱我们的稳定分支。
这样就可以切来切去,片叶不沾身。
</p>
<pre>
@ -517,7 +570,10 @@ README ruby.rb
1 files changed, 2 insertions(+), 2 deletions(-)
</pre>
<p>现在假设我们有段时间不做这个项目了我们做别的去了。当我们回来的时候我们想知道“erlang”分支都是啥而主分支的进度又是怎样。仅仅看分支的名字我们是无从知道自己还在里面有 Haskell 的改动的,但是用 <code>git log</code> 我们就可以。如果您在命令行中提供一个分支名字,它就会显示该分支历史中“可及”的提交,即从该分支创立起可追溯的影响了最终的快照的提交。
<p>现在假设我们有段时间不做这个项目了,我们做别的去了。
当我们回来的时候我们想知道“erlang”分支都是啥而主分支的进度又是怎样。
仅仅看分支的名字,我们是无从知道自己还在里面有 Haskell 的改动的,但是用 <code>git log</code> 我们就可以。
如果你在命令行中提供一个分支名字,它就会显示该分支历史中“可及”的提交,即从该分支创立起可追溯的影响了最终的快照的提交。
</p>
<pre>
@ -533,10 +589,13 @@ b7ae93b added from ruby
17f4acf first commit
</pre>
<p>如此,我们很容易就看到分支里头还包括了 Haskell 代码(高亮显示了)。更酷的是,我们很容易地告诉 Git我们只对某个分支中可及的提交感兴趣。换句话说某分支中与其他分支相比唯一的提交。
<p>如此,我们很容易就看到分支里头还包括了 Haskell 代码(高亮显示了)。
更酷的是,我们很容易地告诉 Git我们只对某个分支中可及的提交感兴趣。换句话说某分支中与其他分支相比唯一的提交。
</p>
<p>在此例中如果我们想要合并“erlang”分支我们需要看当合并的时候都有啥提交会作用到我们的快照上去。我们告诉 Git 的方式是,在不想要看到的分支前放一个 <code>^</code>。例如如果我们想要看“erlang”分支中但不在主分支中的提交我们可以用 <code>erlang ^master</code>,或者反之。
<p>在此例中如果我们想要合并“erlang”分支我们需要看当合并的时候都有啥提交会作用到我们的快照上去。
我们告诉 Git 的方式是,在不想要看到的分支前放一个 <code>^</code>
例如如果我们想要看“erlang”分支中但不在主分支中的提交我们可以用 <code>erlang ^master</code>,或者反之。
</p>
<pre>
@ -551,7 +610,7 @@ ab5ab4c added erlang
</p>
<p class="nutshell">
<b>简而言之</b> 使用 <code>git log</code> 列出促成当前分支目前的快照的提交历史记录。这使能够看到项目是如何到达现在的状况的。
<b>简而言之</b> 使用 <code>git log</code> 列出促成当前分支目前的快照的提交历史记录。这使能够看到项目是如何到达现在的状况的。
</p>
</div>
@ -570,19 +629,26 @@ ab5ab4c added erlang
<div class="block">
<p>
如果您达到一个重要的阶段,并希望永远记住那个特别的提交快照,您可以使用 <code>git tag</code> 给它打上标签。该 <code>tag</code> 命令基本上会给该特殊提交打上永久的书签,从而使您在将来能够用它与其他提交比较。通常,您会在切取一个发布版本或者交付一些东西的时候打个标签。
如果你达到一个重要的阶段,并希望永远记住那个特别的提交快照,你可以使用 <code>git tag</code> 给它打上标签。
<code>tag</code> 命令基本上会给该特殊提交打上永久的书签,从而使你在将来能够用它与其他提交比较。
通常,你会在切取一个发布版本或者交付一些东西的时候打个标签。
</p>
<p>比如说,我们想为我们的 Hello World 项目发布一个“1.0”版本。我们可以用 <code>git tag -a v1.0</code> 命令给最新一次提交打上(<code>HEAD</code>“v1.0”的标签。<code>-a</code> 选项意为“创建一个带注解的标签”,从而使您为标签添加注解。绝大部分时候都会这么做的。不用 <code>-a</code> 选项也可以执行的,但它不会记录这标签是啥时候打的,谁打的,也不会让你添加个标签的注解。我推荐一直创建带注解的标签。</p>
<p>比如说,我们想为我们的 Hello World 项目发布一个“1.0”版本。
我们可以用 <code>git tag -a v1.0</code> 命令给最新一次提交打上(<code>HEAD</code>“v1.0”的标签。
<code>-a</code> 选项意为“创建一个带注解的标签”,从而使你为标签添加注解。绝大部分时候都会这么做的。
不用 <code>-a</code> 选项也可以执行的,但它不会记录这标签是啥时候打的,谁打的,也不会让你添加个标签的注解。
我推荐一直创建带注解的标签。
</p>
<pre>
<b>$ git tag -a v1.0 </b>
</pre>
<p>当您执行 <code>git tag -a</code> 命令时Git 会打开您的编辑器,让您写一句标签注解,就像您给提交写注解一样。
<p>当你执行 <code>git tag -a</code> 命令时Git 会打开你的编辑器,让你写一句标签注解,就像你给提交写注解一样。
</p>
<p>现在,注意当我们执行 <code>git log --decorate</code> 时,我们可以看到我们的标签了:
<p>现在,注意当我们执行 <code>git log --decorate</code> 时,我们可以看到我们的标签了:
</p>
<pre>
@ -601,10 +667,13 @@ ab5ab4c added erlang
* 17f4acf first commit
</pre>
<p>如果我们有新提交,该标签依然会待在该提交的边上,所以我们已经给那个特定快照永久打上标签,并且能够将它与未来的快照做比较。
<p>如果我们有新提交,该标签依然会待在该提交的边上,所以我们已经给那个特定快照永久打上标签,并且能够将它与未来的快照做比较。
</p>
<p>不过我们并不需要给当前提交打标签。如果我们忘了给某个提交打标签,又将它发布了,我们可以给它追加标签。在相同的命令末尾加上提交的 SHA执行就可以了。例如假设我们发布了提交 <code>558151a</code>(几个提交之前的事情了),但是那时候忘了给它打标签。我们现在也可以:</p>
<p>不过我们并不需要给当前提交打标签。如果我们忘了给某个提交打标签,又将它发布了,我们可以给它追加标签。
在相同的命令末尾加上提交的 SHA执行就可以了。
例如,假设我们发布了提交 <code>558151a</code>(几个提交之前的事情了),但是那时候忘了给它打标签。
我们现在也可以:</p>
<pre>
<b>$ git tag -a v0.9 558151a</b>

@ -6,11 +6,12 @@ layout: zh_reference
<h2>获取与创建项目</h2>
<div class="block">
<p>
您得现有一个 Git 仓库,才能用它进行操作。仓库是 Git 存放您要保存的快照的数据的地方。
你得先有一个 Git 仓库,才能用它进行操作。仓库是 Git 存放你要保存的快照的数据的地方。
</p>
<p>
拥有一个 Git 仓库的途径有两种。在已有的目录中,初始化一个新的,其一。比如一个新的项目,或者一个已存在的项目,但该项目尚未有版本控制。如果您想要复制一份别人的项目,或者与别人合作某个项目,也可以从一个公开的 Git 仓库克隆,其二。本章将对两者都做介绍。
<p>拥有一个 Git 仓库的途径有两种。在已有的目录中,初始化一个新的,其一。
比如一个新的项目,或者一个已存在的项目,但该项目尚未有版本控制。如果你想要复制一份别人的项目,
或者与别人合作某个项目,也可以从一个公开的 Git 仓库克隆,其二。本章将对两者都做介绍。
</p>
</div>
</div>
@ -26,14 +27,17 @@ layout: zh_reference
</h2>
<div class="block">
在目录中执行 <code>git init</code>,就可以创建一个 Git 仓库了。比如,我们恰好有个目录,里头有些许文件,如下:
在目录中执行 <code>git init</code>,就可以创建一个 Git 仓库了。比如,我们恰好有个目录,里头有些许文件,如下:
<pre>
<b>$ cd konichiwa</b>
<b>$ ls</b>
README hello.rb
</pre>
在这个项目里头,我们会用各种编程语言写 "Hello World" 实例。到目前为止,我们只有 Ruby 的,不过,这才刚上路嘛。为了开始用 Git 对这个项目作版本控制,我们执行一下 <code>git init</code>
<p>
在这个项目里头,我们会用各种编程语言写 "Hello World" 实例。
到目前为止,我们只有 Ruby 的,不过,这才刚上路嘛。为了开始用 Git 对这个项目作版本控制,我们执行一下 <code>git init</code>
</p>
<pre>
<b>$ git init</b>
@ -41,17 +45,20 @@ Initialized empty Git repository in /opt/konichiwa/.git/
# 在 /opt/konichiwa/.git 目录初始化空 Git 仓库完毕。
</pre>
现在您可以看到在您的项目目录中有个 <code>.git</code> 的子目录。这就是您的 Git 仓库了,所有有关您的此项目的快照数据都存放在这里。
<p>现在你可以看到在你的项目目录中有个 <code>.git</code> 的子目录。
这就是你的 Git 仓库了,所有有关你的此项目的快照数据都存放在这里。
</p>
<pre>
<b>$ ls -a</b>
. .. .git README hello.rb
</pre>
恭喜,现在您就有了一个 Git 仓库的架子,可以开始快照您的项目了。
恭喜,现在你就有了一个 Git 仓库的架子,可以开始快照你的项目了。
<p class="nutshell">
<strong>简而言之</strong>,用 <code>git init</code> 来在目录中创建新的 Git 仓库。您可以在任何时候、任何目录中这么做,完全是本地化的。
<strong>简而言之</strong>,用 <code>git init</code> 来在目录中创建新的 Git 仓库。
你可以在任何时候、任何目录中这么做,完全是本地化的。
</p>
</div>
@ -67,8 +74,8 @@ Initialized empty Git repository in /opt/konichiwa/.git/
<span class="desc">复制一个 Git 仓库,以上下其手</span>
</h2>
<div class="block">
<p>
如果您需要与他人合作一个项目,或者想要复制一个项目,看看代码,您就需要克隆那个项目。执行 <code>git clone [url]</code>[url] 为您想要拷贝的项目,就可以了。
<p>如果你需要与他人合作一个项目,或者想要复制一个项目,看看代码,你就可以克隆那个项目。
执行 <code>git clone [url]</code>[url] 为你想要复制的项目,就可以了。
</p>
<pre>
@ -84,8 +91,9 @@ Resolving deltas: 100% (35/35), done.
README Rakefile <span class="blue">lib</span>
</pre>
<p>
上述操作将拷贝该项目的全部记录,让您本地拥有这些。并且该操作将拷贝该项目的主分支,使您能够查看代码,或进行编辑和修改。进到该目录中,您会看到 <code>.git</code> 子目录。所有的项目数据都存在这里。
<p>上述操作将复制该项目的全部记录,让你本地拥有这些。并且该操作将拷贝该项目的主分支,
使你能够查看代码,或编辑、修改。进到该目录中,你会看到 <code>.git</code> 子目录。
所有的项目数据都存在那里。
</p>
<pre>
@ -98,8 +106,9 @@ HEAD description <span class="blue">info</span> packed-refs
config index <span class="blue">objects</span>
</pre>
<p>
默认情况下Git 会按照您提供的 URL 所指示的项目的名称创建您的本地项目目录。通常就是该 URL 最后一个 <code>/</code> 之后的任何东西。您可以在该命令后(即那个 URL 后面)加上它你想要的目录名。
<p>默认情况下Git 会按照你提供的 URL 所指示的项目的名称创建你的本地项目目录。
通常就是该 URL 最后一个 <code>/</code> 之后的任何东西。如果你想要一个不一样的名字,
你可以在该命令后加上它,就在那个 URL 后面。
</p>
<p class="nutshell">

@ -5,10 +5,13 @@ layout: zh_reference
<h2>Git 手册简介</h2>
<div class="block">
<p>
本站为 Git 参考手册。目的是为学习与记忆 Git 使用中最重要、最普遍的命令提供快速翻阅。这些命令以您可能需要的操作类型划分,并且将提供日常使用中需要的一些常用的命令以及参数。
本站为 Git 参考手册。目的是为学习与记忆 Git 使用中最重要、最普遍的命令提供快速翻阅。
这些命令以你可能需要的操作类型划分,并且将提供日常使用中需要的一些常用的命令以及参数。
</p>
<p>
每个章节都有到下一个章节的链接,所以本手册也可以当作一个入门指导。每个页面还有一个深度 Git 文档阅读的链接,比如官方的使用手册页面或者<a href="http://progit.org">《Pro Git》</a>书中的相关章节,以便于您学习了解更多的 Git 命令。首先,我们要从如何以 Git 的思维方式管理源代码开始。
每个章节都有到下一个章节的链接,所以本手册也可以当作一个入门指导。
每个页面还有一个深度 Git 文档阅读的链接,比如官方的使用手册页面或者 <a href="http://progit.org">《Pro Git》</a>
书中的相关章节,以便于你学习了解更多的 Git 命令。首先,我们要从如何以 Git 的思维方式管理源代码开始。
</p>
</div>
</div>
@ -17,27 +20,30 @@ layout: zh_reference
<h2>如何以 Git 的方式思考</h2>
<div class="block">
<p>
懂得 Git第一件重要的事情就是要知道它与 Subversion、Perforce 或者任何您用过的版本控制工具都有着很大的差别。通常,忘掉您预想的版本控制方式,改以 Git 的方式思考,能够帮助你更好地学习 Git。
懂得 Git第一件重要的事情就是要知道它与 Subversion、Perforce 或者任何你用过的版本控制工具都有着很大的差别。
通常,忘掉你预想的版本控制方式,改以 Git 的方式思考,能够帮助你更好地学习 Git。
</p>
<p>
让我们从头开始。假设您正在设计一个新的源代码管理系统。在您使用某个工具之前,是如何完成基本的源码版本控制工作的呢?十有八九,您只是在项目到达某些阶段的时候,对项目做一份拷贝。
让我们从头开始。假设你正在设计一个新的源代码管理系统。在你使用某个工具之前,是如何完成基本的源码版本控制工作的呢?
十有八九,你只是在项目到达某些阶段的时候,对项目做一份拷贝。
</p>
<pre> $ cp -R project project.bak </pre>
<p>
这样,您就可以在事情变得一团糟的时候很方便的返回到之前的状态,或者通过对比当前的项目与之前的拷贝,看看自己在之后的工作中,都做了哪些修改。
这样,你就可以在事情变得一团糟的时候很方便的返回到之前的状态,或者通过对比当前的项目与之前的拷贝,看看自己在之后的工作中,都做了哪些修改。
</p>
<p>
如果您有点偏执,您可能会经常作上面说的事情,或许还会给项目拷贝加个日期:
如果你有点偏执,你可能会经常作上面说的事情,或许还会给项目拷贝加个日期:
</p>
<pre> $ cp -R project project.2010-06-01.bak </pre>
<p>
如此,您就有了一堆项目在各个阶段的快照,来作比较、查看。使用这种模式,您还可以有效地与人分享项目变更。如果您会在项目到达一定阶段的时候给它打个包,丢到自己的网站上,那其他的开发者们,就能很方便地下载它,做点改动,并给你补丁回馈。
如此,你就有了一堆项目在各个阶段的快照,来作比较、查看。使用这种模式,你还可以有效地与人分享项目变更。
如果你会在项目到达一定阶段的时候给它打个包,丢到自己的网站上,那其他的开发者们,就能很方便地下载它,做点改动,并给你补丁回馈。
</p>
<pre>
@ -50,21 +56,24 @@ layout: zh_reference
$ (通过E-mail发送修改补丁)</pre>
<p>
以此方式,原先的开发者就能将其他人的改动应用到他的项目中去,其他开发者也能了解做的变更。其实这便是许多开源项目采用过多年的协作方式。
以此方式,原先的开发者就能将其他人的改动应用到他的项目中去,其他开发者也能了解做的变更。其实这便是许多开源项目采用过多年的协作方式。
</p>
<p>
这办法其实很好使,所以假设我们现在想要写个工具,让这个办法更快、更简单。我们与其实现一个工具以记录每个文件的版本,可能不如去实现个工具以使创建、储存项目的快照更加方便,不用每次都去人肉作整个项目的拷贝。
这办法其实很好使,所以假设我们现在想要写个工具,让这个办法更快、更简单。
我们与其实现一个工具以记录每个文件的版本,可能不如去实现个工具以使创建、储存项目的快照更加方便,不用每次都去人肉作整个项目的拷贝。
</p>
<p>
这就是 Git 的精要所在。您通过 <code>git commit</code>告诉 Git 您想保存一份项目快照Git 就会为您的项目中的各个文件的当前状态存一份记录。之后,绝大部分的 Git 命令都围绕这些记录展开。比如查看它们的区别diff提取它们的内容等等。
这就是 Git 的精要所在。你通过 <code>git commit</code>告诉 Git 你想保存一份项目快照,
Git 就会为你的项目中的各个文件的当前状态存一份记录。之后,绝大部分的 Git 命令都围绕这些记录展开。
比如查看它们的区别diff提取它们的内容等等。
</p>
<center><img src="./images/snapshots.png"/></center>
<p>
如果您将 Git 看作一个排序、对比以及合并项目更新的工具,那就很容易理解并正确做事了。
如果你将 Git 看作一个排序、对比以及合并项目更新的工具,那就容易理解状况和正确做事了。
</p>
</div>

@ -11,11 +11,14 @@ layout: zh_reference
</h2>
<div class="block">
<p>
现在您有了一堆分支短期的主题、长期的特性或者其它。怎样追踪他们呢Git 有一组工具,可以帮助您弄明白工作是在哪儿完成的,两个分支间的区别是啥,等等。
现在你有了一堆分支,短期的主题、长期的特性或者其它。怎样追踪他们呢?
Git 有一组工具,可以帮助你弄明白工作是在哪儿完成的,两个分支间的区别是啥,等等。
</p>
<p class="nutshell">
<b>简而言之</b> 执行 <code>git log</code> 找到您的项目历史中的特定提交 —— 按作者、日期、内容或者历史记录。执行 <code>git diff</code> 比较历史记录中的两个不同的点 —— 通常是为了看看两个分支有啥区别,或者从某个版本到另一个版本,您的软件都有啥变化。
<b>简而言之</b> 执行 <code>git log</code> 找到你的项目历史中的特定提交 ——
按作者、日期、内容或者历史记录。执行 <code>git diff</code> 比较历史记录中的两个不同的点 ——
通常是为了看看两个分支有啥区别,或者从某个版本到另一个版本,你的软件都有啥变化。
</p>
</div>
</div>
@ -27,12 +30,16 @@ layout: zh_reference
<a target="new" href="http://progit.org/book/ch2-3.html">书k</a>
</span>
<a name="log">git log</a>
<span class="desc">过滤的提交历史记录</span>
<span class="desc">过滤的提交历史记录</span>
</h2>
<div class="block">
<p>
通过查看分支中另一分支看不到的提交记录,我们已经看到如何用 <code>git log</code> 来比较分支。(如果您不记得了,它看起来是这样的:<code>git log branchA ^branchB</code>)。而且,您也可以用 <code>git log</code> 去寻找特定的提交。在此,我们会看到一些更广为使用的 <code>git log</code> 选项,不过哪有很多。完整的清单可以看看官方文档。
<p>
通过查看分支中另一分支看不到的提交记录,我们已经看到如何用 <code>git log</code> 来比较分支。
(如果你不记得了,它看起来是这样的:<code>git log branchA ^branchB</code>)。
而且,你也可以用 <code>git log</code> 去寻找特定的提交。
在此,我们会看到一些更广为使用的 <code>git log</code> 选项,不过哪有很多。
完整的清单可以看看官方文档。
</p>
<h4>
@ -41,7 +48,11 @@ layout: zh_reference
</h4>
<p>
要过滤您的提交历史,只寻找某个特定作者的提交,您可以使用 <code>--author</code> 选项。例如,比方说我们要找 Git 源码中 Linus 提交的部分。我们可以执行类似 <code>git log --author=Linus</code> 的命令。这个查找是大小写敏感的,并且也会检索电子邮箱地址。我在此例中使用 <code>-[number]</code> 选项,以限制结果为最近 [number] 次的提交。
要过滤你的提交历史,只寻找某个特定作者的提交,你可以使用 <code>--author</code> 选项。
例如,比方说我们要找 Git 源码中 Linus 提交的部分。
我们可以执行类似 <code>git log --author=Linus</code> 的命令。
这个查找是大小写敏感的,并且也会检索电子邮箱地址。
我在此例中使用 <code>-[number]</code> 选项,以限制结果为最近 [number] 次的提交。
</p>
<pre>
@ -59,7 +70,9 @@ b532581 make "git unpack-file" a built-in
</h4>
<p>
如果您要指定一个您感兴趣的日期范围以过滤您的提交,可以执行几个选项 —— 我用 <code>--since</code><code>--before</code>,但是您也可以用 <code>--until</code><code>--after</code>。例如,如果我要看 Git 项目中三周前且在四月十八日之后的所有提交,我可以执行这个(我还用了 <code>--no-merges</code> 选项以隐藏合并提交):
如果你要指定一个你感兴趣的日期范围以过滤你的提交,可以执行几个选项 ——
我用 <code>--since</code><code>--before</code>,但是你也可以用 <code>--until</code><code>--after</code>
例如,如果我要看 Git 项目中三周前且在四月十八日之后的所有提交,我可以执行这个(我还用了 <code>--no-merges</code> 选项以隐藏合并提交):
</p>
<pre>
@ -81,7 +94,8 @@ b6c8d2d Documentation/remote-helpers: Add invocation section
</h4>
<p>
您或许还想根据提交注释中的某个特定短语查找提交记录。可以用 <code>--grep</code> 选项。比如说我知道有个提交是有关使用 P4EDITOR 环境变量,又想回忆起那个改动是啥样子的 —— 我可以用 <code>--grep</code> 选项找到该提交。
你或许还想根据提交注释中的某个特定短语查找提交记录。可以用 <code>--grep</code> 选项。
比如说我知道有个提交是有关使用 P4EDITOR 环境变量,又想回忆起那个改动是啥样子的 —— 我可以用 <code>--grep</code> 选项找到该提交。
</p>
<pre>
@ -101,12 +115,15 @@ Date: Wed Mar 12 19:03:24 2008 -0500
</pre>
<p>
Git 会对所有的 <code>--grep</code><code>--author</code> 参数作逻辑或。如果您用 <code>--grep</code><code>--author</code> 时,想看的是某人写作的并且有某个特殊的注释内容的提交记录,您需要加上 <code>--all-match</code> 选项。在这些例子中,我会用上 <code>--format</code> 选项,这样我们就可以看到每个提交的作者是谁了。
Git 会对所有的 <code>--grep</code><code>--author</code> 参数作逻辑或。
如果你用 <code>--grep</code><code>--author</code> 时,想看的是某人写作的并且有某个特殊的注释内容的提交记录,
你需要加上 <code>--all-match</code> 选项。
在这些例子中,我会用上 <code>--format</code> 选项,这样我们就可以看到每个提交的作者是谁了。
</p>
<p>
如果我查找注释内容含有 “p4 depo”的提交我得到了三个提交
</p>
<p>
如果我查找注释内容含有 “p4 depo”的提交我得到了三个提交
</p>
<pre>
<b>$ git log --grep="p4 depo" --format="%h %an %s"</b>
@ -115,9 +132,10 @@ da4a660 Benjamin Sergeant git-p4 fails when cloning a p4 depo.
1cd5738 Simon Hausmann Make incremental imports easier to use by storing the p4 d
</pre>
<p>
如果我加上 <code>--author=Hausmann</code> 参数,与进一步过滤上述结果到 Simon 的唯一提交相反,它会告诉我所有 Simon 的提交或者注释中有“p4 demo”的提交
</p>
<p>
如果我加上 <code>--author=Hausmann</code> 参数,与进一步过滤上述结果到 Simon 的唯一提交相反,
它会告诉我所有 Simon 的提交或者注释中有“p4 demo”的提交
</p>
<pre>
<b>$ git log --grep="p4 depo" --format="%h %an %s" --author="Hausmann"</b>
@ -136,8 +154,8 @@ e96e400 Simon Hausmann git-p4: Fix submit user-interface.