Git 学习笔记
版本控制基本原理
1 有向无环图(DAG)
分布式版本控制系统（DVCS),采用的方式。
- 节点
在DVCS中，每个节点代表项目的一个修订版本，这些对象通常被称为提交。
- 有向边
在DVCS中，每条边是基于两个修订之间的关系生成的。箭头是从父亲修订指向子修订的，代表它们之间的从属关系。修订DAG中的箭头并不一定会形成闭环。通常修订的DAG是从左到右的结构（根节点在左，叶节点在右）或者自下而上的结构（最新的版本在最上面）。而Git命令行中则采用的是自上而下的次序，即最新修订版在最上面。
2 DAG中的节点
- 根节点
这类节点没有父节点（无前驱，入度为0）。在修订DAG结构中至少包含一个根节点，代表初始版本。
- 叶节点(叶子)
这些节点都没有孩子节点(无后继，出度为0)，这样的节点至少有一个。代表项目的最新版本。
修订DAG中的每个节点都有一个分支的HeadHead指向她。
3 标签和分支
分支操作是开发工作中两个不同的工作目录来回切换时发生的。
标签操作是对版本库中特定修订辅以有意义的标记名称的方法。这样可以快速的回退到该版本。
分支和标签有时也称为引用（refs)，它们在修订DAG中代表的含义是一样的，都是修订结构图表中的外部引用(指针)。
图包含两个分支–master(当前分支)和maint，一个名v0.9的标签，一个包含短标识符34ac2的分支节点，一个合并提交3fb00
-
标签
给定版本的符号名称。它永远指向相同的对象，并且不会变更。 -
分支
分支是一系列开发工作的符号名称。创建一个新的提交将会在DAG中生成一个新的节点，并和相关的分支引用关联。
HEAD
HEAD——>HEAD代表了当前分支
HEAD 是Git命令的默认参数，git log 和 git log HEAD的结果是一样的。
下面是一些和HEAD含义类似的引用：
- FETCH_HEAD
记录用户最后一次执行git fetch 或 git pull命令拉取远程版本库的远程分支信息
- ORIG_HEAD
记录当前分支的上一节点的信息。
使用git进行程序开发
- 示例项目新增一个提交之后的修订图
4 索引——提交的暂存区
工作区的每个文件对Git系统来讲分两种：已知的(跟踪文件)和未知的。
对于未知文件Git系统又分两种：未跟踪和已忽略两类。
跟踪的文件一般有两种状态：已提交(未变化)和已修改。已提交状态意味着工作目录下的文件内容和和最近一次提交的修订内容一致。如果文件和最新提交的版本存在差异则认为是已修改的文件。
不过Git系统内部还有另外一种状态，git add 命令加一个文件后。版本控制系统需要在某处存放以上信息,Git系统采用被称为索引(Index)的机制实现此功能，它是存储将要提交信息的暂存区。
5 git diff 最新修订的差异比较示意图
git应用
忽略文件
一般我们总会有些文件无需纳入 Git 的管理，也不希望它们总出现在未跟踪文件列表。 通常都是些自动生成的文 件，比如日志文件，或者编译过程中创建的临时文件等。 在这种情况下，我们可以创建一个名为 .gitignore 的文件，列出要忽略的文件模式。 来看一个实际的例子:
$ cat .gitignore
*.[oa]
*~
第一行告诉 Git 忽略所有以 .o 或 .a 结尾的文件。一般这类对象文件和存档文件都是编译过程中出现的。 第二 行告诉 Git 忽略所有以波浪符(~)结尾的文件，许多文本编辑软件(比如 Emacs)都用这样的文件名保存副 本。 此外，你可能还需要忽略 log，tmp 或者 pid 目录，以及自动生成的文档等等。 要养成一开始就设置好 .gitignore 文件的习惯，以免将来误提交这类无用的文件。
文件 .gitignore 的格式规范如下:
- 所有空行或者以 # 开头的行都会被 Git 忽略。 • 可以使用标准的 glob 模式匹配。
- 匹配模式可以以(/)开头防止递归。
- 匹配模式可以以(/)结尾指定目录。
- 要忽略指定模式以外的文件或目录，可以在模式前加上惊叹号(!)取反。
所谓的 glob 模式是指 shell 所使用的简化了的正则表达式。 星号()匹配零个或多个任意字符;[abc] 匹配
25
任何一个列在方括号中的字符(这个例子要么匹配一个 a，要么匹配一个 b，要么匹配一个 c);问号(? )只匹配一个任意字符;如果在方括号中使用短划线分隔两个字符，表示所有在这两个字符范围内的都可以匹配 (比如 [0-9] 表示匹配所有 0 到 9 的数字)。 使用两个星号() 表示匹配任意中间目录，比如a/**/z 可以匹 配 a/z, a/b/z 或 a/b/c/z等。
我们再看一个 .gitignore 文件的例子:
# no .a files
*.a
# but do track lib.a, even though you're ignoring .a files above
!lib.a
# only ignore the TODO file in the current directory, not subdir/TODO
/TODO
# ignore all files in the build/ directory
build/
# ignore doc/notes.txt, but not doc/server/arch.txt
doc/*.txt
# ignore all .pdf files in the doc/ directory
doc/**/*.pdf
GitHub 有一个十分详细的针对数十种项目及语言的 .gitignore 文件列表，你可以在 https://github.com/github/gitignore 找到它.
查看已暂存和未暂存的修改
如果git status命令的输出对于你来说过于模糊，你想知道具体修改了什么地方，可以用git diff命令。
不加参数直接输入git diff.
-
此命令比较的是工作目录中当前文件和暂存区域快照之间的差异， 也就是修改之后还没有暂存起来的变化内容。
-
若要查看已暂存的将要添加到下次提交里的内容，可以用 git diff --cached 命令。(Git 1.6.1 及更高版本 还允许使用git diff --staged，效果是相同的，但更好记些。)
请注意，git diff 本身只显示尚未暂存的改动，而不是自上次提交以来所做的所有改动。 所以有时候你一下子暂 存了所有更新过的文件后，运行git diff后却什么也没有，就是这个原因。
提交更新
在此之前，请一定要确认还有什么修改过的或新建的文件还没有 git add 过，否则提交的时候不会记录这些还没暂存起来的变化。 这些修改过的文件只保留在本地磁盘。 所 以，每次准备提交前，先用 git status 看下，是不是都已暂存起来了， 然后再运行提交命令:
$git commit:
这种方式会启动文本编辑器以便输入本次提交的说明。 (默认会启用 shell 的环境变量 $EDITOR 所指定的软件， 一般都是vim或emacs。当然也可以按照起步介绍的方式，使用git config --global core.editor命 令设定你喜欢的编辑软件。)
跳过使用暂存区域
Git 提供了一个跳过使用暂 存区域的方式， 只要在提交的时候，给 git commit 加上 -a 选项，Git 就会自动把所有已经跟踪过的文件暂存 起来一并提交，从而跳过git add步骤。
移除文件
要从 Git 中移除某个文件，就必须要从已跟踪文件清单中移除(确切地说，是从暂存区域移除)，然后提交。 可以用git rm命令完成此项工作，并连带从工作目录中删除指定的文件，这样以后就不会出现在未跟踪文件清单中了。
$ git rm PROJECTS.md
rm 'PROJECTS.md'
$ git status
On branch 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就相当于运行了下面三条命令:
$ mv README.md README
$ git rm README.md
$ git add README
查看提交历史
在提交了若干更新，又或者克隆了某个项目之后，你也许想回顾下提交历史。 完成这个任务最简单而又有效的 工具是git log命令。
默认不用任何参数的话，git log会按提交时间列出所有的更新，最近的更新排在最上面。正如你所看到的， 这个命令会列出每个提交的 SHA-1 校验和、作者的名字和电子邮件地址、提交时间以及提交说明。
git log 有许多选项可以帮助你搜寻你所要找的提交， 接下来我们介绍些最常用的。 一个常用的选项是 -p，用来显示每次提交的内容差异。 你也可以加上 -2 来仅显示最近两次提交.
$ git log -p -2
commit ca82a6dff817ec66f44342007202690a93763949
Author: Scott Chacon <schacon@gee-mail.com>
Date: Mon Mar 17 21:52:11 2008 -0700
changed the version number
diff --git a/Rakefile b/Rakefile
index a874b73..8f94139 100644
--- a/Rakefile
+++ b/Rakefile
@@ -5,7 +5,7 @@ require 'rake/gempackagetask'
spec = Gem::Specification.new do |s|
s.platform =
s.name =
- s.version =
+ s.version =
s.author =
s.email =
s.summary =
Gem::Platform::RUBY
"simplegit"
"0.1.0"
"0.1.1"
"Scott Chacon"
"schacon@gee-mail.com"
"A simple gem for using Git in Ruby code."
commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7
Author: Scott Chacon <schacon@gee-mail.com>
Date: Sat Mar 15 16:40:33 2008 -0700
removed unnecessary test
diff --git a/lib/simplegit.rb b/lib/simplegit.rb
index a0a60ae..47c6340 100644
--- a/lib/simplegit.rb
+++ b/lib/simplegit.rb
@@ -18,8 +18,3 @@ class SimpleGit
end
end -
-if $0 == __FILE__
- git = SimpleGit.new
- puts git.show
-end
\ No newline at end of file
也可以为git log附带一系列的总结性选项。 比如说，如果你想看到每次提交的简略的统计信息，你可以使用 --stat选项。
$ git log --stat
commit ca82a6dff817ec66f44342007202690a93763949
Author: Scott Chacon <schacon@gee-mail.com>
Date: Mon Mar 17 21:52:11 2008 -0700
changed the version number
Rakefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7
Author: Scott Chacon <schacon@gee-mail.com>
Date: Sat Mar 15 16:40:33 2008 -0700
removed unnecessary test
lib/simplegit.rb | 5 -----
1 file changed, 5 deletions(-)
commit a11bef06a3f659402fe7563abf99ad00de2209e6
Author: Scott Chacon <schacon@gee-mail.com>
Date: Sat Mar 15 10:31:28 2008 -0700
first commit
README | 6 ++++++
Rakefile | 23 +++++++++++++++++++++++
lib/simplegit.rb | 25 +++++++++++++++++++++++++
3 files changed, 54 insertions(+)
另外一个常用的选项是 --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"
e24e0f7 - rui, 74 minutes ago : commit test
e4a0487 - rui, 2 hours ago : 20190202
4a20921 - rui, 13 hours ago : 20190201
ee5112d - rui, 12 days ago : gitdiff
fdd529c - rui, 12 days ago : index
a653a24 - rui, 12 days ago : 20190121
5d7b126 - rui, 13 days ago : first
git log --pretty=format常用的选项列出了常用的格式占位符写法及其代表的意义。
git log --pretty=format 常用的选项。
| 选项 | 说明 |
|---|---|
| %H | 提交对象(commit)的完整哈希字串 |
| %h | 提交对象的简短哈希字串 |
| %T | 树对象(tree)的完整哈希字串 |
| %t | 树对象的简短哈希字串 |
| %P | 父对象(parent)的完整哈希字串 |
| %p | 父对象的简短哈希字串 |
| %an | 作者(author)的名字 |
| %ae | 作者的电子邮件地址 |
| %ad | 作者修订日期(可以用 --date= 选项定制格式) |
| %ar | 作者修订日期，按多久以前的方式显示 |
| %cn | 提交者(committer)的名字 |
| %ce | 提交者的电子邮件地址 |
| %cd | 提交日期 |
| %cr | 提交日期，按多久以前的方式显示 |
| %s | 提交说明 |
当 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 的常用选项
| 选项 | 说明 |
|---|---|
| -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(后跟指定格式)。 |
限制输出长度
除了定制输出格式的选项之外，git log还有许多非常实用的限制输出长度的选项，也就是只输出部分提交信 息。 之前你已经看到过 -2 了，它只显示最近的两条提交， 实际上，这是 - 选项的写法，其中的 n 可以是任 何整数，表示仅显示最近的若干条提交。 不过实践中我们是不太用这个选项的，Git 在输出所有提交时会自动调 用分页程序，所以你一次只会看到一页的内容。
另外还有按照时间作限制的选项，比如 --since 和 --until 也很有用。 例如，下面的命令列出所有最近两周 内的提交:
git log --since=2.weeks
这个命令可以在多种格式下工作，比如说具体的某一天"2008-01-15"，或者是相对地多久以前"2 years 1 day 3 minutes ago"。
还可以给出若干搜索条件，列出符合的提交。 用 --author 选项显示指定作者的提交，用 --grep 选项搜索提 交说明中的关键字。 (请注意，如果要得到同时满足这两个选项搜索条件的提交，就必须用–all-match 选 项。否则，满足任意一个条件的提交都会被匹配出来)
另一个非常有用的筛选选项是 -S，可以列出那些添加或移除了某些字符串的提交。比如说，你想找出添加或移除了某一个特定函数的引用的提交，你可以这样使用:
$ git log -Sfunction_name
最后一个很实用的 git log 选项是路径(path)， 如果只关心某些文件或者目录的历史提交，可以在 git log 选项的最后指定它们的路径。 因为是放在最后位置上的选项，所以用两个短划线(–)隔开之前的选项和后面限 定的路径名。
在限制git log输出的选项中列出了常用的选项.
Table 3. 限制 git log 输出的选项.
| 选项 | 说明 |
|---|---|
| -(n) | 仅显示最近的 n 条提交 |
| –since, --after | 仅显示指定时间之后的提交。 |
| –until, --before | 仅显示指定时间之前的提交。 |
| –author | 仅显示指定作者相关的提交。 |
| –committer | 仅显示指定提交者相关的提交。 |
| –grep | 仅显示含指定关键字的提交 |
| -S | 仅显示添加或移除了某个关键字的提交 |
来看一个实际的例子，如果要查看 Git 仓库中，2008 年 10 月期间，Junio Hamano 提交的但未合并的测试文 件，可以用下面的查询命令:
$ git log --pretty="%h - %s" --author=gitster --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
563754 - 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
撤销操作
在任何一个阶段，你都有可能想要撤消某些操作。 这里，我们将会学习几个撤消你所做修改的基本工具。 注 意，有些撤消操作是不可逆的。 这是在使用 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 … 来取消暂存。 所 以，我们可以这样来取消暂存 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
| NOTE | 虽然在调用时加上–hard选项可以令git reset成为一个危险的命令(译注:可能导致工作目录中所有当前进度丢失!)，但本例中工作目录内的文件并不会被修改。 不加选项地调用git 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
| IMPORTANT | 你需要知道git checkout – [file]是一个危险的命令，这很重要。你对那个文件做的任何修改都会消失 - 你只是拷贝了另一个文件来覆盖它。 除非你确实清楚不想要那个文件了，否则不要使用这个命令。 |
|---|
远程仓库的使用
查看远程仓库
如果想查看你已经配置的远程仓库服务器，可以运行 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 remote show [remote-name] 命令。 如果想以 一个特定的缩写名运行这个命令，例如 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 push 会自动地推送到哪一个远程分支。 它也同样地列出了哪些 远程分支不在你的本地，哪些远程分支已经从服务器上移除了，还有当你执行git pull时哪些分支会自动合并。
添加远程仓库
我在之前的章节中已经提到并展示了如何添加远程仓库的示例，不过这里将告诉你如何明确地做到这一点。 运 行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-name]
这个命令会访问远程仓库，从中拉取所有你还没有的数据。
如果你使用 clone 命令克隆了一个仓库，命令会自动将其添加为远程仓库并默认以 “origin” 为简写。 所 以，git fetch origin会抓取克隆(或上一次抓取)后新推送的所有工作。必须注意git fetch命令会将 数据拉取到你的本地仓库 - 它并不会自动合并或修改你当前的工作。 当准备好时你必须手动将其合并入你的工 作。
如果你有一个分支设置为跟踪一个远程分支(阅读下一节与Git分支了解更多信息)，可以使用git pull命 令来自动的抓取然后合并远程分支到当前分支。 这对你来说可能是一个更简单或更舒服的工作流程;默认情况 下，git clone命令会自动设置本地master分支跟踪克隆的远程仓库的master分支(或不管是什么名字的默认分支)。运行git pull通常会从最初克隆的服务器上抓取数据并自动尝试合并到当前所在的分支。
推送到远程仓库
当你想分享你的项目时，必须将其推送到上游。 这个命令很简单:git push [remote-name] [branch- name]。 当你想要将 master 分支推送到 origin 服务器时(再次说明，克隆时通常会自动帮你设置好那两个 名字)，那么运行这个命令就可以将你所做的备份到服务器:
$ git push origin master
只有当你有所克隆服务器的写入权限，并且之前没有人推送过时，这条命令才能生效。 当你和其他人在同一时 间克隆，他们先推送到上游然后你再推送到上游，你的推送就会毫无疑问地被拒绝。 你必须先将他们的工作拉 取下来并将其合并进你的工作后才能推送。 阅读 Git 分支 了解如何推送到远程仓库服务器的详细信息。
远程仓库的移除与重命名
如果想要重命名引用的名字可以运行 git remote rename 去修改一个远程仓库的简写名。 例如，想要将 pb 重命名为paul，可以用git remote rename这样做:
$ git remote rename pb paul
$ git remote
origin
paul
值得注意的是这同样也会修改你的远程分支名字。 那些过去引用 pb/master 的现在会引用 paul/master。 如果因为一些原因想要移除一个远程仓库 - 你已经从服务器上搬走了或不再想使用某一个特定的镜像了，又或者
某一个贡献者不再贡献了-可以使用git remote rm:
$ git remote rm paul
$ git remote
origin
打标签
像其他版本控制系统(VCS)一样，Git 可以给历史中的某一个提交打上标签，以示重要。 比较有代表性的是人 们会使用这个功能来标记发布结点(v1.0 等等)。 在本节中，你将会学习如何列出已有的标签、如何创建新标 签、以及不同类型的标签分别是什么。
列出标签
在 Git 中列出已有的标签是非常简单直观的。 只需要输入 git tag:
$ git tag
v0.1
v1.3
这个命令以字母顺序列出标签;但是它们出现的顺序并不重要。
你也可以使用特定的模式查找标签。 例如，Git 自身的源代码仓库包含标签的数量超过 500 个。 如果只对 1.8.5
系列感兴趣，可以运行:
$ git tag -l 'v1.8.5*'
v1.8.5
v1.8.5-rc0
v1.8.5-rc1
v1.8.5-rc2
v1.8.5-rc3
v1.8.5.1
v1.8.5.2
v1.8.5.3
v1.8.5.4
v1.8.5.5
创建标签
Git 使用两种主要类型的标签:
-
轻量标签(lightweight)
一个轻量标签很像一个不会改变的分支 —— 它只是一个特定提交的引用。 -
附注标签(annotated)。
附注标签是存储在 Git 数据库中的一个完整对象。 它们是可以被校验的;其中包含打标签者的名字、电子 邮件地址、日期时间;还有一个标签信息;并且可以使用 GNU Privacy Guard (GPG)签名与验证。
通常建议 创建附注标签，这样你可以拥有以上所有信息;但是如果你只是想用一个临时的标签，或者因为某些原因不想要保存那些信息，轻量标签也是可用的。
附注标签
在 Git 中创建一个附注标签是很简单的。 最简单的方式是当你在运行 tag 命令时指定 -a 选项:
$ git tag -a v1.4 -m 'my version 1.4'
$ git tag
v0.1
v1.3
v1.4
-m 选项指定了一条将会存储在标签中的信息。 如果没有为附注标签指定一条信息，Git 会运行编辑器要求你输 入信息。
通过使用git show命令可以看到标签信息与对应的提交信息:
$ git show v1.4
tag v1.4
Tagger: Ben Straub <ben@straub.cc>
Date: Sat May 3 20:19:12 2014 -0700
my version 1.4
commit ca82a6dff817ec66f44342007202690a93763949
Author: Scott Chacon <schacon@gee-mail.com>
Date: Mon Mar 17 21:52:11 2008 -0700
changed the version number
输出显示了打标签者的信息、打标签的日期时间、附注信息，然后显示具体的提交信息。
轻量标签
轻量标签本质上是将提交校验和存储到一个文件中 - 没有保存任 何其他信息。 创建轻量标签，不需要使用 -a、-s 或 -m 选项，只需要提供标签名字:
$ git tag v1.4-lw
$ git tag
v0.1
v1.3
v1.4
v1.4-lw
v1.5
这时，如果在标签上运行 git show，你不会看到额外的标签信息。 命令只会显示出提交信息:
$ git show v1.4-lw
commit ca82a6dff817ec66f44342007202690a93763949
Author: Scott Chacon <schacon@gee-mail.com>
Date: Mon Mar 17 21:52:11 2008 -0700
changed the version number
后期打标签
你也可以对过去的提交打标签。 假设提交历史是这样的:
$ git log --pretty=oneline
15027957951b64cf874c3557a0f3547bd83b3ff6 Merge branch 'experiment'
a6b4c97498bd301d84096da251c98a07c7723e65 beginning write support
0d52aaab4479697da7686c15f77a3d64d9165190 one more thing
6d52a271eda8725415634dd79daabbc4d9b6008e Merge branch 'experiment'
0b7434d86859cc7b8c3d5e1dddfed66ff742fcbc added a commit function
4682c3261057305bdd616e23b64b0857d832627b added a todo file
166ae0c4d3f420721acbb115cc33848dfcc2121a started write support
9fceb02d0ae598e95dc970b74767f19372d61af8 updated rakefile
964f16d36dfccde844893cac5b347e7b3d44abbc commit the todo
8a5cbc430f1a9c3d00faaeffd07798508422908a updated readme
现在，假设在 v1.2 时你忘记给项目打标签，也就是在 “updated rakefile” 提交。 你可以在之后补上标签。 要 在那个提交上打标签，你需要在命令的末尾指定提交的校验和(或部分校验和):
$ git tag -a v1.2 9fceb02
共享标签
默认情况下，git push 命令并不会传送标签到远程仓库服务器上。 在创建完标签后你必须显式地推送标签到 共享服务器上。 这个过程就像共享远程分支一样 - 你可以运行 git push origin [tagname]。
$ git push origin v1.5
Counting objects: 14, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (12/12), done.
Writing objects: 100% (14/14), 2.05 KiB | 0 bytes/s, done.
Total 14 (delta 3), reused 0 (delta 0)
To git@github.com:schacon/simplegit.git
* [new tag] v1.5 -> v1.5
如果想要一次性推送很多标签，也可以使用带有 --tags 选项的 git push 命令。 这将会把所有不在远程仓库 服务器上的标签全部传送到那里。
$ git push origin --tags
Counting objects: 1, done.
Writing objects: 100% (1/1), 160 bytes | 0 bytes/s, done.
Total 1 (delta 0), reused 0 (delta 0)
To git@github.com:schacon/simplegit.git
* [new tag] v1.4 -> v1.4
* [new tag] v1.4-lw -> v1.4-lw
现在，当其他人从仓库中克隆或拉取，他们也能得到你的那些标签。
检出标签
在 Git 中你并不能真的检出一个标签，因为它们并不能像分支一样来回移动。 如果你想要工作目录与仓库中特定 的标签版本完全一样，可以使用git checkout -b [branchname] [tagname]在特定的标签上创建一个 新分支:
$ git checkout -b version2 v2.0.0
Switched to a new branch 'version2'
当然，如果在这之后又进行了一次提交，version2 分支会因为改动向前移动了，那么 version2 分支就会和 v2.0.0 标签稍微有些不同，这时就应该当心了。
Git别名
在我们结束本章 Git 基础之前，正好有一个小技巧可以使你的 Git 体验更简单、容易、熟悉:别名。 我们不会
在之后的章节中引用到或假定你使用过它们，但是你大概应该知道如何使用它们。
Git 并不会在你输入部分命令时自动推断出你想要的命令。 如果不想每次都输入完整的 Git 命令，可以通过 git
config 文件来轻松地为每一个命令设置一个别名。 这里有一些例子你可以试试:
$ git config --global alias.co checkout
$ git config --global alias.br branch
$ git config --global alias.ci commit
$ git config --global alias.st status
这意味着，当要输入git commit时，只需要输入git ci。随着你继续不断地使用Git，可能也会经常使用其 他命令，所以创建别名时不要犹豫。
在创建你认为应该存在的命令时这个技术会很有用。 例如，为了解决取消暂存文件的易用性问题，可以向 Git 中 添加你自己的取消暂存别名:
$ git config --global alias.unstage 'reset HEAD --'
这会使下面的两个命令等价:
$ git unstage fileA
$ git reset HEAD -- fileA
这样看起来更清楚一些。 通常也会添加一个 last 命令，像这样:
$ git config --global alias.last 'log -1 HEAD'
这样，可以轻松地看到最后一次提交:
$ git last
commit 66938dae3329c7aebe598c2246a8e6af90d04646
Author: Josh Goebel <dreamer3@example.com>
Date: Tue Aug 26 19:48:51 2008 +0800
test for current head
Signed-off-by: Scott Chacon <schacon@example.com>
可以看出，Git 只是简单地将别名替换为对应的命令。 然而，你可能想要执行外部命令，而不是一个 Git 子命 令。 如果是那样的话，可以在命令前面加入 ! 符号。 如果你自己要写一些与 Git 仓库协作的工具的话，那会很 有用。 我们现在演示将 git visual 定义为 gitk 的别名:
$ git config --global alias.visual '!gitk'
Git分支
Git 处理分支的方式可谓是难以置信的轻量，创建新分支这一操作几乎能 在瞬间完成，并且在不同分支之间的切换操作也是一样便捷。 与许多其它版本控制系统不同，Git 鼓励在工作流 程中频繁地使用分支与合并，哪怕一天之内进行许多次。 理解和精通这一特性，你便会意识到 Git 是如此的强大 而又独特，并且从此真正改变你的开发方式。
分支简介
Git 保存的不是文件的变化或者差异，而是一系列不同时刻的文件快照。
在进行提交操作时，Git 会保存一个提交对象(commit object)。知道了 Git 保存数据的方式，我们可以很自 然的想到——该提交对象会包含一个指向暂存内容快照的指针。 但不仅仅是这样，该提交对象还包含了作者的姓 名和邮箱、提交时输入的信息以及指向它的父对象的指针。首次提交产生的提交对象没有父对象，普通提交操作 产生的提交对象有一个父对象，而由多个分支合并产生的提交对象有多个父对象。
分支创建
使用git branch命令：
$ git branch testing
这会在当前所在的提交对象上创建一个指针。
那么，Git 又是怎么知道当前在哪一个分支上呢? 也很简单，它有一个名为 HEAD 的特殊指针。 请注意它和许多其它版本控制系统(如 Subversion 或 CVS)里的 HEAD 概念完全不同。 在 Git 中，它是一个指 针，指向当前所在的本地分支(译注:将 HEAD 想象为当前分支的别名)。 在本例中，你仍然在 master 分支 上。 因为 git branch 命令仅仅 创建 一个新分支，并不会自动切换到新分支中去。
你可以简单地使用git log命令查看各个分支当前所指的对象。提供这一功能的参数是–decorate。
$ git log --oneline --decorate
f30ab (HEAD, master, testing) add feature #32 - ability to add new
34ac2 fixed bug #1328 - stack overflow under certain conditions
98ca9 initial commit of my project
正如你所见，当前 “master” 和 “testing” 分支均指向校验和以 f30ab 开头的提交对象。
分支切换
要切换到一个已存在的分支，你需要使用 git checkout 命令。 我们现在切换到新创建的 testing 分支去:
$ git checkout testing
这样 HEAD 就指向 testing分支了。
那么，这样的实现方式会给我们带来什么好处呢?现在不妨再提交一次:
$ vim test.rb
$ git commit -a -m 'made a change'
如图所示，你的testing分支向前移动了，但是master分支却没有，它仍然指向运行git checkout时所 指的对象。 这就有意思了，现在我们切换回 master 分支看看:
$ git checkout master
这条命令做了两件事。 一是使 HEAD 指回 master 分支，二是将工作目录恢复成 master 分支所指向的快照内 容。 也就是说，你现在做修改的话，项目将始于一个较旧的版本。 本质上来讲，这就是忽略 testing 分支所做 的修改，以便于向另一个方向进行开发。
| 注意 | 分支切换会改变你工作目录中的文件,在切换分支时，一定要注意你工作目录里的文件会被改变。 如果是切换到一个较旧的分支，你 的工作目录会恢复到该分支最后一次提交时的样子。 如果 Git 不能干净利落地完成这个任务， 它将禁止切换分支。 |
|---|
我们不妨再稍微做些修改并提交:
$ vim test.rb
$ git commit -a -m 'made other changes'
现在，这个项目的提交历史已经产生了分叉(参见 项目分叉历史)。 因为刚才你创建了一个新分支，并切换过 去进行了一些工作，随后又切换回 master 分支进行了另外一些工作。 上述两次改动针对的是不同分支:你可以 在不同分支间不断地来回切换和工作，并在时机成熟时将它们合并起来。 而所有这些工作，你需要的命令只有 branch、checkout 和 commit。
你可以简单地使用git log命令查看分叉历史。运行git log --oneline --decorate --graph
–all ，它会输出你的提交历史、各个分支的指向以及项目的分支分叉情况。
$ git log --oneline --decorate --graph --all
* c2b9e (HEAD, master) made other changes
| * 87ab2 (testing) made a change
|/
* f30ab add feature #32 - ability to add new formats to the
* 34ac2 fixed bug #1328 - stack overflow under certain conditions
* 98ca9 initial commit of my project
由于 Git 的分支实质上仅是包含所指对象校验和(长度为 40 的 SHA-1 值字符串)的文件，所以它的创建和销毁 都异常高效。 创建一个新分支就相当于往一个文件中写入 41 个字节(40 个字符和 1 个换行符)，如此的简单 能不快吗?
分支的创建与合并
让我们来看一个简单的分支新建与分支合并的例子，实际工作中你可能会用到类似的工作流。 你将经历如下步 骤:
-
- 开发某个网站。
-
- 为实现某个新的需求，创建一个分支。 3. 在这个分支上开展工作。
正在此时，你突然接到一个电话说有个很严重的问题需要紧急修补。 你将按照如下方式来处理:
-
- 切换到你的线上分支(production branch)。
-
- 为这个紧急任务新建一个分支，并在其中修复它。
-
- 在测试通过之后，切换回线上分支，然后合并这个修补分支，最后将改动推送到线上分支。 4. 切换回你最初工作的分支上，继续工作。
新建分支
首先，我们假设你正在你的项目上工作，并且已经有一些提交。
现在，你已经决定要解决你的公司使用的问题追踪系统中的 #53 问题。 想要新建一个分支并同时切换到那个分
支上，你可以运行一个带有-b参数的git checkout命令:
$ git checkout -b iss53
Switched to a new branch "iss53"
它是下面两条命令的简写:
$ git branch iss53
$ git checkout iss53
你继续在 #53 问题上工作，并且做了一些提交。 在此过程中，iss53 分支在不断的向前推进，因为你已经检出
到该分支(也就是说，你的 HEAD 指针指向了 iss53 分支)
$ vim index.html
$ git commit -a -m 'added a new footer [issue 53]'
现在你接到那个电话，有个紧急问题等待你来解决。 有了 Git 的帮助，你不必把这个紧急问题和 iss53 的修改 混在一起，你也不需要花大力气来还原关于 53# 问题的修改，然后再添加关于这个紧急问题的修改，最后将这 个修改提交到线上分支。 你所要做的仅仅是切换回 master 分支。
但是，在你这么做之前，要留意你的工作目录和暂存区里那些还没有被提交的修改，它可能会和你即将检出的分 支产生冲突从而阻止 Git 切换到该分支。 最好的方法是，在你切换分支之前，保持好一个干净的状态。 有一些方法可以绕过这个问题(即，保存进度(stashing) 和 修补提交(commit amending))，我们会在 储藏与清理 中看到关于这两个命令的介绍。 现在，我们假设你已经把你的修改全部提交了，这时你可以切换回 master分支了:
$ git checkout master
Switched to branch 'master'
这个时候，你的工作目录和你在开始 #53 问题之前一模一样，现在你可以专心修复紧急问题了。 请牢记:当你 切换分支的时候，Git 会重置你的工作目录，使其看起来像回到了你在那个分支上最后一次提交的样子。 Git 会 自动添加、删除、修改文件以确保此时你的工作目录和这个分支最后一次提交时的样子一模一样。
接下来，你要修复这个紧急问题。 让我们建立一个针对该紧急问题的分支(hotfix branch)，在该分支上工作 直到问题解决:
$ git checkout -b hotfix
Switched to a new branch 'hotfix'
$ vim index.html
$ git commit -a -m 'fixed the broken email address'
[hotfix 1fb7853] fixed the broken email address
1 file changed, 2 insertions(+)
你可以运行你的测试，确保你的修改是正确的，然后将其合并回你的 master 分支来部署到线上。 你可以使用
git merge命令来达到上述目的:
$ git checkout master
$ git merge hotfix
Updating f42c576..3a0874c
Fast-forward
index.html | 2 ++
1 file changed, 2 insertions(+)
在合并的时候，你应该注意到了"快进(fast-forward)"这个词。 由于当前 master 分支所指向的提交是你当前 提交(有关 hotfix 的提交)的直接上游，所以 Git 只是简单的将指针向前移动。 换句话说，当你试图合并两个 分支时，如果顺着一个分支走下去能够到达另一个分支，那么 Git 在合并两者的时候，只会简单的将指针向前推 进(指针右移)，因为这种情况下的合并操作没有需要解决的分歧——这就叫做 “快进(fast-forward)”。
现在，最新的修改已经在 master 分支所指向的提交快照中，你可以着手发布该修复了。
关于这个紧急问题的解决方案发布之后，你准备回到被打断之前时的工作中。 然而，你应该先删除 hotfix 分 支，因为你已经不再需要它了 —— master 分支已经指向了同一个位置。 你可以使用带 -d 选项的 git branch 命令来删除分支:
$ git branch -d hotfix
Deleted branch hotfix (3a0874c).
现在你可以切换回你正在工作的分支继续你的工作，也就是针对 #53 问题的那个分支(iss53 分支)。
$ git checkout iss53
Switched to branch "iss53"
$ vim index.html
$ git commit -a -m 'finished the new footer [issue 53]'
[iss53 ad82d7a] finished the new footer [issue 53]
1 file changed, 1 insertion(+)
你在 hotfix 分支上所做的工作并没有包含到 iss53 分支中。 如果你需要拉取 hotfix 所做的修改，你可以使 用git merge master命令将master分支合并入iss53分支，或者你也可以等到iss53分支完成其使命， 再将其合并回 master 分支。
分支合并
假设你已经修正了 #53 问题，并且打算将你的工作合并入 master 分支。 为此，你需要合并 iss53 分支到 master 分支，这和之前你合并 hotfix 分支所做的工作差不多。 你只需要检出到你想合并入的分支，然后运行 git merge命令:
$ git checkout master
Switched to branch 'master'
$ git merge iss53
Merge made by the 'recursive' strategy.
index.html | 1 +
1 file changed, 1 insertion(+)
这和你之前合并 hotfix 分支的时候看起来有一点不一样。 在这种情况下，你的开发历史从一个更早的地方开 始分叉开来(diverged)。 因为，master 分支所在提交并不是 iss53 分支所在提交的直接祖先，Git不得不做一些额外的工作。 出现这种情况的时候，Git 会使用两个分支的末端所指的快照(C4 和 C5 )以及这两个分支的工作祖先(C2)，做一个简单的三方合并。
和之前将分支指针向前推进所不同的是，Git 将此次三方合并的结果做了一个新的快照并且自动创建一个新的提
交指向它。 这个被称作一次合并提交，它的特别之处在于他有不止一个父提交。
需要指出的是，Git 会自行决定选取哪一个提交作为最优的共同祖先，并以此作为合并的基础;这和更加古老的 CVS 系统或者 Subversion (1.5 版本之前)不同，在这些古老的版本管理系统中，用户需要自己选择最佳的合 并基础。 Git 的这个优势使其在合并操作上比其他系统要简单很多。
既然你的修改已经合并进来了，你已经不再需要 iss53 分支了。 现在你可以在任务追踪系统中关闭此项任务， 并删除这个分支。
$ git branch -d iss53
遇到冲突时的分支合并
有时候合并操作不会如此顺利。 如果你在两个不同的分支中，对同一个文件的同一个部分进行了不同的修 改，Git 就没法干净的合并它们。 如果你对 #53 问题的修改和有关 hotfix 的修改都涉及到同一个文件的同一 处，在合并它们的时候就会产生合并冲突:
$ git merge iss53
Auto-merging index.html
CONFLICT (content): Merge conflict in index.html
Automatic merge failed; fix conflicts and then commit the result.
此时 Git 做了合并，但是没有自动地创建一个新的合并提交。 Git 会暂停下来，等待你去解决合并产生的冲突。 你可以在合并冲突后的任意时刻使用git status命令来查看那些因包含合并冲突而处于未合并 (unmerged)状态的文件:
$ git status
On branch master
You have unmerged paths.
(fix conflicts and run "git commit")
Unmerged paths:
(use "git add <file>..." to mark resolution)
both modified: index.html
no changes added to commit (use "git add" and/or "git commit -a")
任何因包含合并冲突而有待解决的文件，都会以未合并状态标识出来。 Git 会在有冲突的文件中加入标准的冲突 解决标记，这样你可以打开这些包含冲突的文件然后手动解决冲突。 出现冲突的文件会包含一些特殊区段，看 起来像下面这个样子:
<<<<<<< HEAD:index.html
<div id="footer">contact : email.support@github.com</div>
=======
<div id="footer">
please contact us at support@github.com
</div>
>>>>>>> iss53:index.html
这表示 HEAD 所指示的版本(也就是你的 master 分支所在的位置，因为你在运行 merge 命令的时候已经检出 到了这个分支)在这个区段的上半部分(======= 的上半部分)，而 iss53 分支所指示的版本在 ======= 的下半部分。 为了解决冲突，你必须选择使用由 ======= 分割的两部分中的一个，或者你也可以自行合并这些内容。 例如，你可以通过把这段内容换成下面的样子来解 决冲突:
<div id="footer">
please contact us at email.support@github.com
</div>
上述的冲突解决方案仅保留了其中一个分支的修改，并且 <<<<<<< , ======= , 和 >>>>>>> 这些行被完全删除 了。 在你解决了所有文件里的冲突之后，对每个文件使用 git add 命令来将其标记为冲突已解决。 一旦暂存这 些原本有冲突的文件，Git 就会将它们标记为冲突已解决。
如果你想使用图形化工具来解决冲突，你可以运行git mergetool，该命令会为你启动一个合适的可视化合并 工具，并带领你一步一步解决这些冲突:
$ git mergetool
This message is displayed because 'merge.tool' is not configured.
See 'git mergetool --tool-help' or 'git help config' for more details.
'git mergetool' will now attempt to use one of the following tools:
opendiff kdiff3 tkdiff xxdiff meld tortoisemerge gvimdiff diffuse
diffmerge ecmerge p4merge araxis bc3 codecompare vimdiff emerge
Merging:
index.html
Normal merge conflict for 'index.html':
{local}: modified file
{remote}: modified file
Hit return to start merge resolution tool (opendiff):
如果你想使用除默认工具(在这里 Git 使用 opendiff 做为默认的合并工具，因为作者在 Mac 上运行该程序) 外的其他合并工具，你可以在 “下列工具中(one of the following tools)” 这句后面看到所有支持的合并工 具。 然后输入你喜欢的工具名字就可以了。
| NOTE | 如果你需要更加高级的工具来解决复杂的合并冲突，我们会在 高级合并 介绍更多关于分支合并 的内容 |
|---|
等你退出合并工具之后，Git 会询问刚才的合并是否成功。 如果你回答是，Git 会暂存那些文件以表明冲突已解 决:你可以再次运行git status来确认所有的合并冲突都已被解决:
$ git status
On branch master
All conflicts fixed but you are still merging.
(use "git commit" to conclude merge)
Changes to be committed
modified: index.html
如果你对结果感到满意，并且确定之前有冲突的的文件都已经暂存了，这时你可以输入git commit来完成合 并提交。 默认情况下提交信息看起来像下面这个样子:
Merge branch 'iss53'
Conflicts:
index.html
#
# It looks like you may be committing a merge.
# If this is not correct, please remove the file
# .git/MERGE_HEAD
# and try again.
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch master
# All conflicts fixed but you are still merging.
#
# Changes to be committed:
# modified: index.html
#
如果你觉得上述的信息不够充分，不能完全体现分支合并的过程，你可以修改上述信息，添加一些细节给未来检 视这个合并的读者一些帮助，告诉他们你是如何解决合并冲突的，以及理由是什么。
分支管理
git branch命令不只是可以创建与删除分支。如果不加任何参数运行，会得到当前所有分支的一个列表。
如果需要查看每一个分支的最后一次提 交，可以运行git branch -v命令.
–merged 与 --no-merged 这两个有用的选项可以过滤这个列表中已经合并或尚未合并到当前分支的分支。 如果要查看哪些分支已经合并到当前分支，可以运行git branch --merged:
$ git branch --merged
iss53
* master
因为之前已经合并了 iss53 分支，所以现在看到它在列表中。 在这个列表中分支名字前没有 * 号的分支通常可 以使用git branch -d删除掉;你已经将它们的工作整合到了另一个分支，所以并不会失去任何东西。
查看所有包含未合并工作的分支，可以运行git branch --no-merged。
还未合并的工作，尝试使用 git branch -d 命令删除它时会失败。如果真的想要删除分支并丢掉那些工作，如同帮助信息里所指出的，可以使用 -D 选项强制删除它。
分支开发工作流
长期分支
因为 Git 使用简单的三方合并，所以就算在一段较长的时间内，反复把一个分支合并入另一个分支，也不是什 么难事。 也就是说，在整个项目开发周期的不同阶段，你可以同时拥有多个开放的分支;你可以定期地把某些 特性分支合并入其他分支中。
许多使用 Git 的开发者都喜欢使用这种方式来工作，比如只在 master 分支上保留完全稳定的代码——有可能仅 仅是已经发布或即将发布的代码。 他们还有一些名为 develop 或者 next 的平行分支，被用来做后续开发或者 测试稳定性——这些分支不必保持绝对稳定，但是一旦达到稳定状态，它们就可以被合并入 master 分支了。 这 样，在确保这些已完成的特性分支(短期分支，比如之前的 iss53 分支)能够通过所有测试，并且不会引入更 多 bug 之后，就可以合并入主干分支中，等待下一次的发布。
事实上我们刚才讨论的，是随着你的提交而不断右移的指针。 稳定分支的指针总是在提交历史中落后一大截，而前沿分支的指针往往比较靠前。
通常把他们想象成流水线(work silos)可能更好理解一点，那些经过测试考验的提交会被遴选到更加稳定的流
水线上去。
你可以用这种方法维护不同层次的稳定性。 一些大型项目还有一个 proposed(建议) 或 pu: proposed updates(建议更新)分支，它可能因包含一些不成熟的内容而不能进入 next 或者 master 分支。 这么做的 目的是使你的分支具有不同级别的稳定性;当它们具有一定程度的稳定性后，再把它们合并入具有更高级别稳定 性的分支中。 再次强调一下，使用多个长期分支的方法并非必要，但是这么做通常很有帮助，尤其是当你在一 个非常庞大或者复杂的项目中工作时。
特性分支
特性分支对任何规模的项目都适用。 特性分支是一种短期分支，它被用来实现单一特性或其相关工作。 也许你 从来没有在其他的版本控制系统(VCS)上这么做过，因为在那些版本控制系统中创建和合并分支通常很费劲。 然而，在 Git 中一天之内多次创建、使用、合并、删除分支都很常见。
你已经在上一节中你创建的 iss53 和 hotfix 特性分支中看到过这种用法。 你在上一节用到的特性分支 (iss53 和 hotfix 分支)中提交了一些更新，并且在它们合并入主干分支之后，你又删除了它们。 这项技术 能使你快速并且完整地进行上下文切换(context-switch)——因为你的工作被分散到不同的流水线中，在不同 的流水线中每个分支都仅与其目标特性相关，因此，在做代码审查之类的工作的时候就能更加容易地看出你做了 哪些改动。 你可以把做出的改动在特性分支中保留几分钟、几天甚至几个月，等它们成熟之后再合并，而不用 在乎它们建立的顺序或工作进度。
考虑这样一个例子，你在 master 分支上工作到 C1，这时为了解决一个问题而新建 iss91 分支，在 iss91 分 支上工作到 C4，然而对于那个问题你又有了新的想法，于是你再新建一个 iss91v2 分支试图用另一种方法解决 那个问题，接着你回到 master 分支工作了一会儿，你又冒出了一个不太确定的想法，你便在 C10 的时候新建 一个 dumbidea 分支，并在上面做些实验。 你的提交历史看起来像下面这个样子:
现在，我们假设两件事情:你决定使用第二个方案来解决那个问题，即使用在 iss91v2 分支中方案;另外，你将 dumbidea 分支拿给你的同事看过之后，结果发现这是个惊人之举。 这时你可以抛弃 iss91 分支(即丢弃 C5 和 C6 提交)，然后把另外两个分支合并入主干分支。 最终你的提交历史看起来像下面 这个样子:
远程分支
远程跟踪分支是远程分支状态的引用。 它们是你不能移动的本地引用，当你做任何网络通信操作时，它们会自 动移动。 远程跟踪分支像是你上次连接到远程仓库时，那些分支所处状态的书签。
服务器上的Git
协议
Git 可以使用四种主要的协议来传输资料:本地协议(Local)，HTTP 协议，SSH(Secure Shell)协议及 Git 协议。 在此，我们将会讨论那些协议及哪些情形应该使用(或避免使用)他们。
本地协议
最基本的就是 本地协议(Local protocol) ，其中的远程版本库就是硬盘内的另一个目录。 这常见于团队每一 个成员都对一个共享的文件系统(例如一个挂载的 NFS)拥有访问权，或者比较少见的多人共用同一台电脑的情 况。 后者并不理想，因为你的所有代码版本库如果长存于同一台电脑，更可能发生灾难性的损失。
如果你使用共享文件系统，就可以从本地版本库克隆(clone)、推送(push)以及拉取(pull)。 像这样去克 隆一个版本库或者增加一个远程到现有的项目中，使用版本库路径作为 URL。 例如，克隆一个本地版本库，可 以执行如下的命令:
$ git clone /opt/git/project.git
或你可以执行这个命令:
$ git clone file:///opt/git/project.git
如果在 URL 开头明确的指定 file://，那么 Git 的行为会略有不同。 如果仅是指定路径，Git 会尝试使用硬链 接(hard link)或直接复制所需要的文件。 如果指定 file://，Git 会触发平时用于网路传输资料的进程，那 通常是传输效率较低的方法。 指定 file:// 的主要目的是取得一个没有外部参考(extraneous references) 或对象(object)的干净版本库副本– 通常是在从其他版本控制系统导入后或一些类似情况需要这么做。 在此我们将使用普通路径，因为这样通常更快。
要增加一个本地版本库到现有的 Git 项目，可以执行如下的命令:
$ git remote add local_proj /opt/git/project.git
HTTP协议
- 智能(Snart) HTTP协议
- 哑(Dumb) HTTP协议
4444
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
