10
10
分支与合并
11
11
</ h2 >
12
12
< div class ="block ">
13
- < p > 分支是我最喜欢的 Git 特性之一。如果您用过其他版本控制系统,把您所知的分支给忘记 ,倒可能更有帮助些 —— 事实上,以我们使用分支的方式,把 Git 的分支看作 < i > 上下文</ i > 反而更合适。当您检出分支时,您可以在两三个不同的分支之间来回切换 。
13
+ < p > 分支是我最喜欢的 Git 特性之一。如果你用过其他版本控制系统,把你所知的分支给忘记 ,倒可能更有帮助些 —— 事实上,以我们使用分支的方式,把 Git 的分支看作 < i > 上下文</ i > 反而更合适。当你检出分支时,你可以在两三个不同的分支之间来回切换 。
14
14
</ p >
15
15
16
16
< p class ="nutshell ">
17
- < b > 一言以蔽之</ b > ,您可以执行 < code > git branch (branchname)</ code > 来创建分支,使用 < code > git checkout (branchname)</ code > 命令切换到该分支,在该分支的上下文环境中,提交快照等,之后可以很容易地来回切换。当您切换分支的时候 ,Git 会用该分支的最后提交的快照替换您的工作目录的内容 ,所以多个分支不需要多个目录。使用 < code > git merge</ code > 来合并分支。您可以多次合并到统一分支 ,也可以选择在合并之后直接删除被并入的分支。
17
+ < b > 一言以蔽之</ b > ,你可以执行 < code > git branch (branchname)</ code > 来创建分支,使用 < code > git checkout (branchname)</ code > 命令切换到该分支,在该分支的上下文环境中,提交快照等,之后可以很容易地来回切换。当你切换分支的时候 ,Git 会用该分支的最后提交的快照替换你的工作目录的内容 ,所以多个分支不需要多个目录。使用 < code > git merge</ code > 来合并分支。你可以多次合并到统一分支 ,也可以选择在合并之后直接删除被并入的分支。
18
18
</ p >
19
19
20
20
</ div >
42
42
</ h2 >
43
43
44
44
< div class ="block ">
45
- < p > < code > git branch</ code > 命令是 Git 中的通用分支管理工具,可以通过它完成多项任务。我们先说您会用到的最多的命令 —— 列出分支、创建分支和删除分支。我们还会介绍用来切换分支的 < code > git checkout</ code > 命令。
45
+ < p > < code > git branch</ code > 命令是 Git 中的通用分支管理工具,可以通过它完成多项任务。我们先说你会用到的最多的命令 —— 列出分支、创建分支和删除分支。我们还会介绍用来切换分支的 < code > git checkout</ code > 命令。
46
46
</ p >
47
47
48
48
< h4 >
49
49
git branch
50
50
< small > 列出可用的分支</ small >
51
51
</ h4 >
52
52
53
- < p > 没有参数是,< code > git branch</ code > 会列出您在本地的分支。您所在的分支的行首会有个星号作标记。如果您开启了 < a href ="http://progit.org/book/ch7-1.html#colors_in_git "> 彩色模式</ a > ,当前分支会用绿色显示。
53
+ < p > 没有参数是,< code > git branch</ code > 会列出你在本地的分支。你所在的分支的行首会有个星号作标记。如果你开启了 < a href ="http://progit.org/book/ch7-1.html#colors_in_git "> 彩色模式</ a > ,当前分支会用绿色显示。
54
54
</ p >
55
55
56
56
< pre >
57
57
$ git branch
58
58
* < span class ="green "> master</ span >
59
59
</ pre >
60
60
61
- < p > 此例的意思就是,我们有一个叫做“master”的分支,并且该分支是当前分支。当您执行 < code > git init</ code > 的时候,缺省情况下 Git 就会为您创建 “master”分支。但是这名字一点特殊意味都没有 —— 事实上您并不非得要一个叫做 “master”的分支。不过由于它是缺省分支名的缘故,绝大部分项目都有这个分支。
61
+ < p > 此例的意思就是,我们有一个叫做“master”的分支,并且该分支是当前分支。当你执行 < code > git init</ code > 的时候,缺省情况下 Git 就会为你创建 “master”分支。但是这名字一点特殊意味都没有 —— 事实上你并不非得要一个叫做 “master”的分支。不过由于它是缺省分支名的缘故,绝大部分项目都有这个分支。
62
62
</ p >
63
63
64
64
< h4 >
75
75
testing
76
76
</ pre >
77
77
78
- < p > 现在我们可以看到,有了一个新分支。当您以此方式在上次提交更新之后创建了新分支 ,如果后来又有更新提交,然后又切换到了“testing”分支,Git 将还原您的工作目录到您创建分支时候的样子 —— 您可以把它看作一个记录您当前进度的书签 。让我们实际运用看看 —— 我们用 < code > git checkout (branch)</ code > 切换到我们要修改的分支。
78
+ < p > 现在我们可以看到,有了一个新分支。当你以此方式在上次提交更新之后创建了新分支 ,如果后来又有更新提交,然后又切换到了“testing”分支,Git 将还原你的工作目录到你创建分支时候的样子 —— 你可以把它看作一个记录你当前进度的书签 。让我们实际运用看看 —— 我们用 < code > git checkout (branch)</ code > 切换到我们要修改的分支。
79
79
</ p >
80
80
81
81
< pre >
115
115
</ h4 >
116
116
117
117
< p >
118
- 通常情况下,您会更希望立即切换到新分支 ,从而在该分支中操作,然后当此分支的开发日趋稳定时,将它合并到稳定版本的分支(例如“master”)中去。执行 < code > git branch newbranch; git checkout newbranch</ code > 也很简单,不过 Git 还为您提供了快捷方式 :< code > git checkout -b newbranch</ code > 。
118
+ 通常情况下,你会更希望立即切换到新分支 ,从而在该分支中操作,然后当此分支的开发日趋稳定时,将它合并到稳定版本的分支(例如“master”)中去。执行 < code > git branch newbranch; git checkout newbranch</ code > 也很简单,不过 Git 还为你提供了快捷方式 :< code > git checkout -b newbranch</ code > 。
119
119
</ p >
120
120
121
121
< pre >
@@ -142,11 +142,11 @@ <h4>
142
142
README hello.rb more.txt test.txt
143
143
</ pre >
144
144
145
- < p > 如您所见 ,我们创建了一个分支,在该分支的上下文中移除了一些文件,然后切换回我们的主分支,那些文件又回来了。使用分支将工作切分开来,从而让我们能够在不同上下文中做事,并来回切换。
145
+ < p > 如你所见 ,我们创建了一个分支,在该分支的上下文中移除了一些文件,然后切换回我们的主分支,那些文件又回来了。使用分支将工作切分开来,从而让我们能够在不同上下文中做事,并来回切换。
146
146
</ p >
147
147
148
148
< p >
149
- 创建新分支,在其中完成一部分工作,完成之后将它合并到主分支并删除。您会觉得这很方便 ,因为这么做很快很容易。如此,当您觉得这部分工作并不靠谱 ,舍弃它很容易。并且,如果您必须回到稳定分支做些事情 ,也可以很方便地这个独立分支的工作先丢在一边,完成要事之后再切换回来。
149
+ 创建新分支,在其中完成一部分工作,完成之后将它合并到主分支并删除。你会觉得这很方便 ,因为这么做很快很容易。如此,当你觉得这部分工作并不靠谱 ,舍弃它很容易。并且,如果你必须回到稳定分支做些事情 ,也可以很方便地这个独立分支的工作先丢在一边,完成要事之后再切换回来。
150
150
</ p >
151
151
152
152
< h4 >
@@ -180,11 +180,11 @@ <h2>
180
180
< a target ="new " href ="http://progit.org/book/ch3-2.html#basic_merging "> book</ a >
181
181
</ span >
182
182
< a name ="merge "> git merge</ a >
183
- < span class ="desc "> 将分支合并到您的当前分支 </ span >
183
+ < span class ="desc "> 将分支合并到你的当前分支 </ span >
184
184
</ h2 >
185
185
186
186
< div class ="block ">
187
- < p > 一旦某分支有了独立内容,您终究会希望将它合并回到您的主分支。您可以使用 < code > git merge</ code > 命令将任何分支合并到当前分支中去。我们那上例中的“removals”分支为例。假设我们创建了一个分支,移除了一些文件,并将它提交到该分支,其实该分支是与我们的主分支(也就是“master”)独立开来的。要想将这些移除操作包含在主分支中,您可以将 “removals”分支合并回去。
187
+ < p > 一旦某分支有了独立内容,你终究会希望将它合并回到你的主分支。你可以使用 < code > git merge</ code > 命令将任何分支合并到当前分支中去。我们那上例中的“removals”分支为例。假设我们创建了一个分支,移除了一些文件,并将它提交到该分支,其实该分支是与我们的主分支(也就是“master”)独立开来的。要想将这些移除操作包含在主分支中,你可以将 “removals”分支合并回去。
188
188
</ p >
189
189
190
190
< pre >
209
209
更多复杂合并
210
210
</ h4 >
211
211
212
- < p > 当然,合并并不仅仅是简单的文件添加、移除的操作,Git 也会合并修改 —— 事实上,它很会合并修改。举例,我们看看在某分支中编辑某个文件,然后在另一个分支中把它的名字改掉再做些修改,最后将这俩分支合并起来。您觉得会变成一坨 shi?我们试试看。
212
+ < p > 当然,合并并不仅仅是简单的文件添加、移除的操作,Git 也会合并修改 —— 事实上,它很会合并修改。举例,我们看看在某分支中编辑某个文件,然后在另一个分支中把它的名字改掉再做些修改,最后将这俩分支合并起来。你觉得会变成一坨 shi?我们试试看。
213
213
</ p >
214
214
215
215
< pre >
342
342
nearly every programming language.
343
343
</ pre >
344
344
345
- < p > 您可以看到 ,Git 在产生合并冲突的地方插入了标准的与 Subversion 很像的合并冲突标记。轮到我们去解决这些冲突了。在这里我们就手动把它解决。如果您要 Git 打开一个图形化的合并工具,可以看看 < a href ="http://www.kernel.org/pub/software/scm/git/docs/git-mergetool.html "> git 合并工具</ a > (比如 kdiff3、emerge、p4merge 等)。
345
+ < p > 你可以看到 ,Git 在产生合并冲突的地方插入了标准的与 Subversion 很像的合并冲突标记。轮到我们去解决这些冲突了。在这里我们就手动把它解决。如果你要 Git 打开一个图形化的合并工具,可以看看 < a href ="http://www.kernel.org/pub/software/scm/git/docs/git-mergetool.html "> git 合并工具</ a > (比如 kdiff3、emerge、p4merge 等)。
346
346
</ p >
347
347
348
348
< pre >
360
360
This project has examples of hello world in
361
361
</ pre >
362
362
363
- < p > 在 Git 中,处理合并冲突的时候有个很酷的提示。如果您执行 < code > git diff</ code > ,就像我演示的这样,它会告诉您冲突的两方,和您是如何解决的 。现在是时候把它标记为已解决了。在 Git 中,我们可以用 < code > git add</ code > —— 要告诉 Git 文件冲突已经解决,您必须把它写入缓存区 。
363
+ < p > 在 Git 中,处理合并冲突的时候有个很酷的提示。如果你执行 < code > git diff</ code > ,就像我演示的这样,它会告诉你冲突的两方,和你是如何解决的 。现在是时候把它标记为已解决了。在 Git 中,我们可以用 < code > git add</ code > —— 要告诉 Git 文件冲突已经解决,你必须把它写入缓存区 。
364
364
</ p >
365
365
366
366
< pre >
@@ -396,14 +396,14 @@ <h2>
396
396
< div class ="block ">
397
397
398
398
< p >
399
- 到目前为止,我们已经提交快照到项目中,在不同的各自分离的上下文中切换,但假如我们忘了自己是如何到目前这一步的那该怎么办?或者假如我们想知道此分支与彼分支到底有啥区别?Git 提供了一个告诉您使您达成当前快照的所有提交消息的工具 ,叫做 < code > git log</ code > 。
399
+ 到目前为止,我们已经提交快照到项目中,在不同的各自分离的上下文中切换,但假如我们忘了自己是如何到目前这一步的那该怎么办?或者假如我们想知道此分支与彼分支到底有啥区别?Git 提供了一个告诉你使你达成当前快照的所有提交消息的工具 ,叫做 < code > git log</ code > 。
400
400
</ p >
401
401
402
402
< p >
403
- 要理解日志(log)命令,您需要了解当执行 < code > git commit</ code > 以存储一个快照的时候,都有啥信息被保存了。除了文件详单、提交消息和提交者的信息,Git 还保存了您的此次提交所基于的快照 。也就是,假如您克隆了一个项目,您是在什么快照的基础上做的修改而得到新保存的快照的 ?这有益于为项目进程提供上下文,使 Git 能够弄明白谁做了什么改动。如果 Git 有您的快照所基于的快照的话,它就能自动判断您都改变了什么 。而新提交所基于的提交,被称作新提交的“父亲”。
403
+ 要理解日志(log)命令,你需要了解当执行 < code > git commit</ code > 以存储一个快照的时候,都有啥信息被保存了。除了文件详单、提交消息和提交者的信息,Git 还保存了你的此次提交所基于的快照 。也就是,假如你克隆了一个项目,你是在什么快照的基础上做的修改而得到新保存的快照的 ?这有益于为项目进程提供上下文,使 Git 能够弄明白谁做了什么改动。如果 Git 有你的快照所基于的快照的话,它就能自动判断你都改变了什么 。而新提交所基于的提交,被称作新提交的“父亲”。
404
404
</ p >
405
405
406
- < p > 某分支的按时间排序的“父亲”列表,当您在该分支时 ,可以执行 < code > git log</ code > 以查看。例如,如果我们在本章中操作的 Hello World 项目中执行 < code > git log</ code > ,我们可以看到已提交的消息。
406
+ < p > 某分支的按时间排序的“父亲”列表,当你在该分支时 ,可以执行 < code > git log</ code > 以查看。例如,如果我们在本章中操作的 Hello World 项目中执行 < code > git log</ code > ,我们可以看到已提交的消息。
407
407
408
408
< pre >
409
409
< b > $ git log</ b >
474
474
* 17f4acf first commit
475
475
</ pre >
476
476
477
- < p > 现在我们可以更清楚明了地看到何时工作分叉、又何时归并。这对查看发生了什么、应用了什么改变很有帮助,并且极大地帮助您管理您的分支 。让我们创建一个分支,在里头做些事情,然后切回到主分支,也做点事情,然后看看 < code > log</ code > 命令是如何帮助我们理清这俩分支上都发生了啥的。
477
+ < p > 现在我们可以更清楚明了地看到何时工作分叉、又何时归并。这对查看发生了什么、应用了什么改变很有帮助,并且极大地帮助你管理你的分支 。让我们创建一个分支,在里头做些事情,然后切回到主分支,也做点事情,然后看看 < code > log</ code > 命令是如何帮助我们理清这俩分支上都发生了啥的。
478
478
</ p >
479
479
480
480
< p > 首先我们创建一个分支,来添加 Erlang 编程语言的 Hello World 示例 —— 我们想要在一个分支里头做这个,以避免让可能还不能工作的代码弄乱我们的稳定分支。这样就可以切来切去,片叶不沾身。
517
517
1 files changed, 2 insertions(+), 2 deletions(-)
518
518
</ pre >
519
519
520
- < p > 现在假设我们有段时间不做这个项目了,我们做别的去了。当我们回来的时候,我们想知道“erlang”分支都是啥,而主分支的进度又是怎样。仅仅看分支的名字,我们是无从知道自己还在里面有 Haskell 的改动的,但是用 < code > git log</ code > 我们就可以。如果您在命令行中提供一个分支名字 ,它就会显示该分支历史中“可及”的提交,即从该分支创立起可追溯的影响了最终的快照的提交。
520
+ < p > 现在假设我们有段时间不做这个项目了,我们做别的去了。当我们回来的时候,我们想知道“erlang”分支都是啥,而主分支的进度又是怎样。仅仅看分支的名字,我们是无从知道自己还在里面有 Haskell 的改动的,但是用 < code > git log</ code > 我们就可以。如果你在命令行中提供一个分支名字 ,它就会显示该分支历史中“可及”的提交,即从该分支创立起可追溯的影响了最终的快照的提交。
521
521
</ p >
522
522
523
523
< pre >
551
551
</ p >
552
552
553
553
< p class ="nutshell ">
554
- < b > 一言以蔽之</ b > 使用 < code > git log</ code > 列出促成当前分支目前的快照的提交历史记录。这使您能够看到项目是如何到达现在的状况的 。
554
+ < b > 一言以蔽之</ b > 使用 < code > git log</ code > 列出促成当前分支目前的快照的提交历史记录。这使你能够看到项目是如何到达现在的状况的 。
555
555
</ p >
556
556
557
557
</ div >
@@ -570,16 +570,16 @@ <h2>
570
570
< div class ="block ">
571
571
572
572
< p >
573
- 如果您达到一个重要的阶段 ,并希望永远记住那个特别的提交快照,您可以使用 < code > git tag</ code > 给它打上标签。该 < code > tag</ code > 命令基本上会给该特殊提交打上永久的书签,从而使您在将来能够用它与其他提交比较 。通常,您会在切取一个发布版本或者交付一些东西的时候打个标签 。
573
+ 如果你达到一个重要的阶段 ,并希望永远记住那个特别的提交快照,你可以使用 < code > git tag</ code > 给它打上标签。该 < code > tag</ code > 命令基本上会给该特殊提交打上永久的书签,从而使你在将来能够用它与其他提交比较 。通常,你会在切取一个发布版本或者交付一些东西的时候打个标签 。
574
574
</ p >
575
575
576
- < p > 比如说,我们想为我们的 Hello World 项目发布一个“1.0”版本。我们可以用 < code > git tag -a v1.0</ code > 命令给最新一次提交打上(< code > HEAD</ code > )“v1.0”的标签。< code > -a</ code > 选项意为“创建一个带注解的标签”,从而使您为标签添加注解 。绝大部分时候都会这么做的。不用 < code > -a</ code > 选项也可以执行的,但它不会记录这标签是啥时候打的,谁打的,也不会让你添加个标签的注解。我推荐一直创建带注解的标签。</ p >
576
+ < p > 比如说,我们想为我们的 Hello World 项目发布一个“1.0”版本。我们可以用 < code > git tag -a v1.0</ code > 命令给最新一次提交打上(< code > HEAD</ code > )“v1.0”的标签。< code > -a</ code > 选项意为“创建一个带注解的标签”,从而使你为标签添加注解 。绝大部分时候都会这么做的。不用 < code > -a</ code > 选项也可以执行的,但它不会记录这标签是啥时候打的,谁打的,也不会让你添加个标签的注解。我推荐一直创建带注解的标签。</ p >
577
577
578
578
< pre >
579
579
< b > $ git tag -a v1.0 </ b >
580
580
</ pre >
581
581
582
- < p > 当您执行 < code > git tag -a</ code > 命令时,Git 会打开您的编辑器,让您写一句标签注解,就像您给提交写注解一样 。
582
+ < p > 当你执行 < code > git tag -a</ code > 命令时,Git 会打开你的编辑器,让你写一句标签注解,就像你给提交写注解一样 。
583
583
</ p >
584
584
585
585
< p > 现在,注意当我们执行 < code > git log --decorate</ code > 时,我们可以看到我们的标签了:
0 commit comments