第一版地址： https://git-scm.com/book/zh/v1 ******* 【本笔记是根据第一版记录】
第二版地址： https://git-scm.com/book/zh/v2
Chapter 1： 起步
1.1 起步 - 关于版本控制
Git 和其他版本控制系统的主要差别在于，Git 只关心文件数据的整体是否发生变化，而大多数其他系统则只关心文件内容的具体差异。
1.2 起步 - Git 简史
1.3 起步 - Git 基础
在 Git 中的绝大多数操作都只需要访问本地文件和资源，不用连网。
Git 使用 SHA-1 算法计算数据的校验和，通过对文件的内容或目录的结构计算出一个 SHA-1 哈希值，作为指纹字符串。该字串由 40 个十六进制字符（0-9 及 a-f）组成。Git 数据库中的东西都是用此哈希值来作索引的，而不是靠文件名。
对于任何一个文件，在 Git 内都只有三种状态：已提交（committed），已修改（modified）和已暂存（staged）。
1、已提交表示该文件已经被安全地保存在本地数据库中了；
2、已修改表示修改了某个文件，但还没有提交保存；
3、已暂存表示把已修改的文件放在下次提交时要保存的清单中。
Git 管理项目时，文件流转的三个工作区域：Git 的工作目录，暂存区域，以及本地仓库。
所谓的暂存区域只不过是个简单的文件，一般都放在 Git 目录中。有时候人们会把这个文件叫做索引文件，不过标准说法还是叫暂存区域。
基本的 Git 工作流程如下：
在工作目录中修改某些文件。
对修改后的文件进行快照，然后保存到暂存区域。
提交更新，将保存在暂存区域的文件快照永久转储到 Git 目录中。
1.4 起步 - 安装 Git
1.5 起步 - 初次运行 Git 前的配置
一般在新的系统上，我们都需要先配置下自己的 Git 工作环境。
Git 提供了一个叫做 git config 的工具，专门用来配置或读取相应的工作环境变量。这些变量可以存放在以下三个不同的地方：
1、/etc/gitconfig 文件：系统中对所有用户都普遍适用的配置。若使用 git config 时用 --system 选项，读写的就是这个文件。
2、~/.gitconfig 文件：用户目录下的配置文件只适用于该用户。若使用 git config 时用 --global 选项，读写的就是这个文件。
3、当前项目的 Git 目录中的配置文件（也就是工作目录中的 .git/config 文件）：这里的配置仅仅针对当前项目有效。
【 注 意 】每一个级别的配置都会覆盖上层的相同配置，所以 .git/config 里的配置会覆盖 /etc/gitconfig 中的同名变量。
用户信息：
第一个要配置的是你个人的用户名称和电子邮件地址。这两条配置很重要，每次 Git 提交时都会引用这两条信息，说明是谁提交了更新，所以会随更新内容一起被永久纳入历史记录：
$ git config --global user.name "John Doe"
$ git config --global user.email [email protected]
要检查已有的配置信息，可以使用 git config --list 命令. 有时候会看到重复的变量名，那就说明它们来自不同的配置文件（比如 /etc/gitconfig 和 ~/.gitconfig），不过最终 Git 实际采用的是最后一个。
1.6 起步 - 获取帮助
1.7 起步 - 小结
Chapter 2:Git 基础
2.1 Git 基础 - 取得项目的 Git 仓库
取得项目的 Git 仓库
有两种取得 Git 项目仓库的方法。
1、第一种是在现存的目录下，通过导入所有文件来创建新的 Git 仓库。要对现有的某个项目开始用 Git 管理，只需到此项目所在的目录，执行：$ git init
2、第二种是从已有的 Git 仓库克隆出一个新的镜像仓库来。从现有仓库克隆： 克隆仓库的命令格式为 git clone [url]。
Git 收取的是项目历史的所有数据（每一个文件的每一个版本），服务器上有的数据克隆之后本地也都有了。
如果希望在克隆的时候，自己定义要新建的项目目录名称，可以在上面的命令末尾指定新的名字： $ git clone git://github.com/schacon/grit.git mygrit
Git 支持许多数据传输协议。之前的例子使用的是 git:// 协议，不过你也可以用 http(s):// 或者 user@server:/path.git 表示的 SSH 传输协议。
2.2 Git 基础 - 记录每次更新到仓库
工作目录下面的所有文件都不外乎这两种状态：已跟踪或未跟踪。
1、检查当前文件状态。要确定哪些文件当前处于什么状态，可以用 git status 命令。
2、跟踪新文件
使用命令 git add 开始跟踪一个新文件，然后该文件处于暂存状态。
在 git add 后面可以指明要跟踪的文件或目录路径。如果是目录的话，就说明要递归跟踪该目录下的所有文件。（译注：其实 git add 的潜台词就是把目标文件快照放入暂存区域，也就是 add file into staged area，同时未曾跟踪过的文件标记为需要跟踪。这样就好理解后续 add 操作的实际意义了。）git add 命令这是个多功能命令，根据目标文件的状态不同，此命令的效果也不同：可以用它开始跟踪新文件，或者把已跟踪的文件放到暂存区，还能用于合并时把有冲突的文件标记为已解决状态等。
3、暂存已修改文件
4、忽略某些文件
我们可以创建一个名为 .gitignore 的文件，列出要忽略的文件模式。要养成一开始就设置好 .gitignore 文件的习惯，以免将来误提交这类无用的文件。
文件 .gitignore 的格式规范如下：
a、所有空行或者以注释符号 ＃ 开头的行都会被 Git 忽略。
b、可以使用标准的 glob 模式匹配。
c、匹配模式最后跟反斜杠（/）说明要忽略的是目录。
d、要忽略指定模式以外的文件或目录，可以在模式前加上惊叹号（!）取反。
【glob 模式】 是指 shell 所使用的简化了的正则表达式。星号（*）匹配零个或多个任意字符；[abc] 匹配任何一个列在方括号中的字符（这个例子要么匹配一个 a，要么匹配一个 b，要么匹配一个 c）；问号（?）只匹配一个任意字符；如果在方括号中使用短划线分隔两个字符，表示所有在这两个字符范围内的都可以匹配（比如 [0-9] 表示匹配所有 0 到 9 的数字）。
5、查看已暂存和未暂存的更新
git diff ： 此命令比较的是工作目录中当前文件和暂存区域快照之间的差异，也就是修改之后还没有暂存起来的变化内容。
git diff --staged : 可以查看已经暂存起来的文件和上次提交时的快照之间的差异。
【请注意，】单单 git diff 不过是显示还没有暂存起来的改动，而不是这次工作和上次提交之间的差异。所以有时候你一下子暂存了所有更新过的文件后，运行 git diff 后却什么也没有，就是这个原因。
6、提交更新
git commit -m"message"
设定自己喜欢的编辑软件： git config --global core.editor "'/Applications/Sublime Text.app/Contents/SharedSupport/bin/subl' -n -w"
【记住】，提交时记录的是放在暂存区域的快照，任何还未暂存的仍然保持已修改状态，可以在下次提交时纳入版本管理。每一次运行提交操作，都是对你项目作一次快照，以后可以回到这个状态，或者进行比较。
7、跳过使用暂存区域
只要在提交的时候，给 git commit 加上 -a 选项，Git 就会自动把所有已经跟踪过的文件暂存起来一并提交，从而跳过 git add 步骤
8、移除文件
git rm ： 从 Git 中移除某个文件，就必须要从已跟踪文件清单中移除（确切地说，是从暂存区域移除），然后提交
如果删除之前修改过并且已经放到暂存区域的话，则必须要用强制删除选项 -f（译注：即 force 的首字母），以防误删除文件后丢失修改的内容。
仅是从跟踪清单中删除，但仍然希望保留在当前工作目录中，用 --cached 选项即可。$ git rm --cached readme.txt
9、移动文件
$ git mv file_from file_to
2.3 Git 基础 - 查看提交历史： https://git-scm.com/book/zh/v1/Git-基础-查看提交历史
1、查看提交历史
$ git log
默认不用任何参数的话，git log 会按提交时间列出所有的更新，最近的更新排在最上面。
常用 -p 选项展开显示每次提交的内容差异，用 -2 则仅显示最近的两次更新: $ git log -p -2
--stat，仅显示简要的增改行数统计
--pretty 选项，可以指定使用完全不同于默认格式的方式展示提交历史。比如用 oneline 将每个提交放在一行显示，这在提交数很大时非常有用。另外还有 short，full 和 fuller 可以用，展示的信息或多或少有些不同.
如：$ git log --pretty=oneline
format，可以定制要显示的记录格式，这样的输出便于后期编程提取分析。
如：$ git log --pretty=format:"%h - %an, %ar : %s"
=========[start 列出了常用的格式占位符写法及其代表的意义。]===========
选项 说明
%H 提交对象（commit）的完整哈希字串
%h 提交对象的简短哈希字串
%T 树对象（tree）的完整哈希字串
%t 树对象的简短哈希字串
%P 父对象（parent）的完整哈希字串
%p 父对象的简短哈希字串
%an 作者（author）的名字
%ae 作者的电子邮件地址
%ad 作者修订日期（可以用 -date= 选项定制格式）
%ar 作者修订日期，按多久以前的方式显示
%cn 提交者(committer)的名字
%ce 提交者的电子邮件地址
%cd 提交日期
%cr 提交日期，按多久以前的方式显示
%s 提交说明
======================[ end 列出了常用的格式占位符写法及其代表的意义。]===========
===========================[start git log 参数]======================
选项 说明
-p 按补丁格式显示每个更新之间的差异。
--word-diff 按 word diff 格式显示差异。
--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 的简化用法。
=============================[ end git log 参数]=====================
2、限制输出长度
之前我们已经看到过 -2 了，它只显示最近的两条提交，实际上，这是 -<n> 选项的写法，其中的 n 可以是任何自然数，表示仅显示最近的若干条提交。
还有按照时间作限制的选项，比如 --since 和 --until。下面的命令列出所有最近两周内的提交：$ git log --since=2.weeks
用 --author 选项显示指定作者的提交，用 --grep 选项搜索提交说明中的关键字。（请注意，如果要得到同时满足这两个选项搜索条件的提交，就必须用 --all-match 选项。否则，满足任意一个条件的提交都会被匹配出来）
***另一个真正实用的git log选项是路径(path)，如果只关心某些文件或者目录的历史提交，可以在 git log 选项的最后指定它们的路径。因为是放在最后位置上的选项，所以用两个短划线（--）隔开之前的选项和后面限定的路径名。
==============================[start 常用选项]=========================
选项 说明
-(n) 仅显示最近的 n 条提交
--since, --after 仅显示指定时间之后的提交。
--until, --before 仅显示指定时间之前的提交。
--author 仅显示指定作者相关的提交。
--committer 仅显示指定提交者相关的提交。
=========================[ end 常用选项]===========================
*** 来看一个实际的例子，如果要查看 Git 仓库中，2008 年 10 月期间，Junio Hamano 提交的但未合并的测试脚本（位于项目的 t/ 目录下的文件），可以用下面的查询命令：
$ git log --pretty="%h - %s" --author=gitster --since="2008-10-01" --before="2008-11-01" --no-merges -- t/
2.4 Git 基础 - 撤消操作 : https://git-scm.com/book/zh/v1/Git-基础-撤消操作
1、撤消操作
【请注意】，有些撤销操作是不可逆的，所以请务必谨慎小心，一旦失误，就有可能丢失部分工作成果。
2、修改最后一次提交
有时候我们提交完了才发现漏掉了几个文件没有加，或者提交信息写错了。想要撤消刚才的提交操作，可以使用 --amend 选项重新提交
$ git commit -m 'initial commit'
$ git add forgotten_file
$ git commit --amend
上面的三条命令最终只是产生一个提交，第二个提交命令修正了第一个的提交内容。
3、取消已经暂存的文件
可以使用 git reset HEAD <file>... 的方式取消暂存。我们来试试取消暂存 benchmarks.rb 文件：$ git reset HEAD benchmarks.rb
4、取消对文件的修改
$ git checkout -- fileName 。 如： $ git checkout -- benchmarks.rb
【注意】：这条命令有些危险，所有对文件的修改都没有了，因为我们刚刚把之前版本的文件复制过来重写了此文件。所以在用这条命令前，请务必确定真的不再需要保留刚才的修改。如果只是想回退版本，同时保留刚才的修改以便将来继续工作，
【记住】，任何已经提交到 Git 的都可以被恢复。即便在已经删除的分支中的提交，或者用 --amend 重新改写的提交，都可以被恢复。所以，你可能失去的数据，仅限于没有提交过的，对 Git 来说它们就像从未存在过一样。
=====================[start 小结]==========================
1、github仓库：
2、git本地仓库： 修改最后一次提交，git commit --amend。
3、git暂存区，将暂存的文件转换到工作目录： 可以使用 git reset HEAD <file>... 的方式取消暂存。
4、取消对文件的修改： $ git checkout -- fileName
=======================[ end 2小结]========================
2.5 Git 基础 - 远程仓库的使用 ： https://git-scm.com/book/zh/v1/Git-基础-远程仓库的使用
1、查看当前的远程库
要查看当前配置有哪些远程仓库，可以用 git remote 命令，它会列出每个远程库的简短名字。一个名为 origin 的远程库，Git 默认使用这个名字来标识你所克隆的原始仓库。
加上 -v 选项（译注：此为 --verbose 的简写，取首字母），显示对应的克隆地址.
$ git remote -v
2、添加远程仓库
要添加一个新的远程仓库，可以指定一个简单的名字，以便将来引用，运行 git remote add [shortname] [url]： $ git remote add pb（仓库地址） git://github.com/paulboone/ticgit.git
3、从远程仓库抓取数据
从远程仓库抓取数据到本地：$ git fetch [remote-name]。
此命令会到远程仓库中拉取所有你本地仓库中还没有的数据。运行完成后，你就可以在本地访问该远程仓库中的所有分支，将其中某个分支合并到本地，或者只是取出某个分支
如果是克隆了一个仓库，此命令会自动将远程仓库归于 origin 名下。所以，git fetch origin 会抓取从你上次克隆以来别人上传到此远程仓库中的所有更新（或是上次 fetch 以来别人提交的更新）。
【有一点很重要，需要记住】，fetch 命令只是将远端的数据拉到本地仓库，并不自动合并到当前工作分支，只有当你确实准备好了，才能手工合并。
如果设置了某个分支用于跟踪某个远端仓库的分支，可以使用 git pull 命令自动抓取数据下来，然后将远端分支自动合并到本地仓库中当前分支。在日常工作中我们经常这么用，既快且好。实际上，默认情况下 git clone 命令本质上就是自动创建了本地的 master 分支用于跟踪远程仓库中的 master 分支（假设远程仓库确实有 master 分支）。所以一般我们运行 git pull，目的都是要从原始克隆的远端仓库中抓取数据后，合并到工作目录中的当前分支。
4、推送数据到远程仓库：项目进行到一个阶段，要同别人分享目前的成果，可以将本地仓库中的数据推送到远程仓库。
$ git push [remote-name] [branch-name]
如果要把本地的 master 分支推送到 origin 服务器上（再次说明下，克隆操作会自动使用默认的 master 和 origin 名字）
$ git push origin master
【注意】如果在你推数据前，已经有其他人推送了若干更新，那你的推送操作就会被驳回。你必须先把他们的更新抓取到本地，合并到自己的项目中，然后才可以再次推送。
5、查看远程仓库信息
$ git remote show [remote-name] 查看某个远程仓库的详细信息
如： $ git remote show origin
6、远程仓库的删除和重命名
可以用 git remote rename 命令修改某个远程仓库在本地的简称: $ git remote rename oldName newName
【注意】，对远程仓库的重命名，也会使对应的分支名称发生变化，原来的 pb/master 分支现在成了 paul/master。
移除对应的远端仓库，可以运行 git remote rm 命令：$ git remote rm [remote-name]
2.6 Git 基础 - 打标签 ： https://git-scm.com/book/zh/v1/Git-基础-打标签
2.7 Git 基础 - 技巧和窍门 : https://git-scm.com/book/zh/v1/Git-基础-技巧和窍门
1、自动补全
2、Git 命令别名
2.8 Git 基础 - 小结
Chapter 3 ：Git 分支
Git 鼓励在工作流程中频繁使用分支与合并，哪怕一天之内进行许多次都没有关系。理解分支的概念并熟练运用后，你才会意识到为什么 Git 是一个如此强大而独特的工具，并从此真正改变你的开发方式。
3.1 Git 分支 - 何谓分支 ：https://git-scm.com/book/zh/v1/Git-分支-何谓分支
Git 保存的不是文件差异或者变化量，而只是一系列文件快照。
***【提交过程原理】暂存操作会对每一个文件计算校验和（即第一章中提到的 SHA-1 哈希字串），然后把当前版本的文件快照保存到 Git 仓库中（Git 使用 blob 类型的对象存储这些快照），并将校验和加入暂存区域：
$ git add README test.rb LICENSE
$ git commit -m 'initial commit of my project'
当使用 git commit 新建一个提交对象前，Git 会先计算每一个子目录（本例中就是项目根目录）的校验和，然后在 Git 仓库中将这些目录保存为树（tree）对象。之后 Git 创建的提交对象，除了包含相关提交信息以外，还包含着指向这个树对象（项目根目录）的指针，如此它就可以在将来需要的时候，重现此次快照的内容了。
【Git 中的分支】，其实本质上仅仅是个指向 commit 对象的可变指针。Git 会使用 master 作为分支的默认名字。在若干次提交后，你其实已经有了一个指向最后一次提交对象的 master 分支，它在每次提交的时候都会自动向前移动。
问题 1、Git 又是如何创建一个新的分支的呢？比如新建一个 testing 分支，可以使用 git branch 命令：
$ git branch testing 这会在当前 commit 对象上新建一个分支指针（见图 3-4）。
问题 2、Git 是如何知道你当前在哪个分支上工作的呢？其实答案也很简单，它保存着一个名为 HEAD 的特别指针。它是一个指向你正在工作中的本地分支的指针（译注：将 HEAD 想象为当前分支的别名。）
【注意】运行 git branch 命令，仅仅是建立了一个新的分支，但不会自动切换到这个分支中去，所以在这个例子中，我们依然还在 master 分支里工作。
要切换到其他分支，可以执行 git checkout 命令。我们现在转换到新建的 testing 分支：
$ git checkout testing 这样 HEAD 就指向了 testing 分支。非常有趣，现在 testing 分支向前移动了一格，而 master 分支仍然指向原先 git checkout 时所在的 commit 对象。
切换分支： $ git checkout master
这条命令做了两件事。它把 HEAD 指针移回到 master 分支，并把工作目录中的文件换成了 master 分支所指向的快照内容。也就是说，现在开始所做的改动，将始于本项目中一个较老的版本。它的主要作用是将 testing 分支里作出的修改暂时取消，这样你就可以向另一个方向进行开发。
由于 Git 中的分支实际上仅是一个包含所指对象校验和（40 个字符长度 SHA-1 字串）的文件，所以创建和销毁一个分支就变得非常廉价。说白了，新建一个分支就是向一个文件写入 41 个字节（外加一个换行符）那么简单，当然也就很快了。
因为每次提交时都记录了祖先信息（译注：即 parent 对象），将来要合并分支时，寻找恰当的合并基础（译注：即共同祖先）的工作其实已经自然而然地摆在那里了，所以实现起来非常容易。
Git 鼓励开发者频繁使用分支，正是因为有着这些特性作保障。
3.2 Git 分支 - 分支的新建与合并 : https://git-scm.com/book/zh/v1/Git-分支-分支的新建与合并
=================[start 场景假设]===============================================
分支的新建与合并
现在让我们来看一个简单的分支与合并的例子，实际工作中大体也会用到这样的工作流程：
开发某个网站。
为实现某个新的需求，创建一个分支。
在这个分支上开展工作。
假设此时，你突然接到一个电话说有个很严重的问题需要紧急修补，那么可以按照下面的方式处理：
返回到原先已经发布到生产服务器上的分支。
为这次紧急修补建立一个新分支，并在其中修复问题。
通过测试后，回到生产服务器所在的分支，将修补分支合并进来，然后再推送到生产服务器上。
切换到之前实现新需求的分支，继续工作
==================[ end 场景假设]===============================================
1、查询分支列表：$ git branch 注意看 master 分支前的 * 字符：它表示当前所在的分支。也就是说，如果现在提交更新，master 分支将随着开发进度前移。
要查看各个分支最后一个提交对象的信息，运行 git branch -v：
$ git branch -v
2、分支的新建与切换
a、创建分支不切换： $ git branch newBranchName
b、新建并切换到该分支 ： $ git checkout -b newBranchName
c、切换分支： $ git checkout branchName
【注意】：不过在此之前，留心你的暂存区或者工作目录里，那些还没有提交的修改，它会和你即将检出的分支产生冲突从而阻止 Git 为你切换分支。切换分支的时候最好保持一个清洁的工作区域。
【*** 这一点值得牢记 ***】：Git 会把工作目录的内容恢复为检出某分支时它所指向的那个提交对象的快照。它会自动添加、删除和修改文件以确保目录的内容和你当时提交时完全一样。
d、合并分支：
步骤一：切换到合并分支的目标分支： $ git checkout master
步骤二：将需要合并的分支的内容合并到当前的分支： $ git merge hotfix 效果：将分支 hotfix 的内容合并到分支 master中。
【请注意】，合并时出现了“Fast forward”的提示。由于当前 master 分支所在的提交对象是要并入的 hotfix 分支的直接上游，Git 只需把 master 分支指针直接右移。换句话说，如果顺着一个分支走下去可以到达另一个分支的话，那么 Git 在合并两者时，只会简单地把指针右移，因为这种单线的历史分支不存在任何需要解决的分歧，所以这种合并过程可以称为快进（Fast forward）。
d、删除分支： $ git branch -d branchName
e、本地分支重命名 ：
$ git branch -m oldbranchname newbranchname
或者
$ git branch -m newbranchname 这个操作会直接修改当前分支的名称为 newbranchname
3、分支的合并
4、遇到冲突时的分支合并
如果在不同的分支中都修改了同一个文件的同一部分，Git 就无法干净地把两者合到一起（译注：逻辑上说，这种问题只能由人来裁决。）
要看看哪些文件在合并时发生冲突，可以用 git status 查阅： $ git status
任何包含未解决冲突的文件都会以未合并（unmerged）的状态列出。
解决冲突的办法无非是二者选其一或者由你亲自整合到一起。在解决了所有文件里的所有冲突后，运行 git add 将把它们标记为已解决状态（译注：实际上就是来一次快照保存到暂存区域。）。因为一旦暂存，就表示冲突已经解决。
5、筛选分支
要从该清单中筛选出你已经（或尚未）与当前分支合并的分支，可以用 --merged 和 --no-merged 选项。
git branch --merged 查看哪些分支已被并入当前分支（译注：也就是说哪些分支是当前分支的直接上游。）
一般来说，列表中没有 * 的分支通常都可以用 git branch -d 来删掉。原因很简单，既然已经把它们所包含的工作整合到了其他分支，删掉也不会损失什么。
另外可以用 git branch --no-merged 查看尚未合并的工作
3.3 Git 分支 - 分支的管理 : https://git-scm.com/book/zh/v1/Git-分支-分支的管理
3.4 Git 分支 - 利用分支进行开发的工作流程
1、长期分支
你可以同时拥有多个开放的分支，每个分支用于完成特定的任务，随着开发的推进，你可以随时把某个特性分支的成果并到其他分支中。
2、特性分支
【*** 请务必牢记 ***】这些分支全部都是本地分支，这一点很重要。当你在使用分支及合并的时候，一切都是在你自己的 Git 仓库中进行的 — 完全不涉及与服务器的交互。
3.5 Git 分支 - 远程分支 ：https://git-scm.com/book/zh/v1/Git-分支-远程分支
远程分支（remote branch）是对远程仓库中的分支的索引。它们是一些无法移动的本地分支；只有在 Git 进行网络交互时才会更新。远程分支就像是书签，提醒着你上次连接远程仓库时上面各分支的位置。
我们用 (远程仓库名)/(分支名) 这样的形式表示远程分支。同 origin 仓库通讯时 master 分支的样子，就应该查看 origin/master 分支。
【克隆代码的逻辑】：假设你们团队有个地址为 git.ourcompany.com 的 Git 服务器。如果你从这里克隆，Git 会自动为你将此远程仓库命名为 origin，并下载其中所有的数据，建立一个指向它的 master 分支的指针，在本地命名为 origin/master，但你无法在本地更改其数据。接着，Git 建立一个属于你自己的本地 master 分支，始于 origin 上 master 分支相同的位置，你可以就此开始工作。一次 Git 克隆会建立你自己的本地分支 master 和远程分支 origin/master，并且将它们都指向 origin 上的 master 分支。
运行 git fetch origin 来同步远程服务器上的数据到本地。该命令首先找到 origin 是哪个服务器（本例为 git.ourcompany.com），从上面获取你尚未拥有的数据，更新你本地的数据库，然后把 origin/master 的指针移到它最新的位置上
1、推送本地分支
要想和其他人分享某个本地分支，你需要把它推送到一个你拥有写权限的远程仓库。你创建的本地分支不会因为你的写入操作而被自动同步到你引入的远程服务器上，你需要明确地执行推送分支的操作。换句话说，对于无意分享的分支，你尽管保留为私人分支好了，而只推送那些协同工作要用到的特性分支。
【值得注意的是】如果要把该远程分支的内容合并到当前分支，可以运行 git merge origin/serverfix。如果想要一份自己的 serverfix 来开发，可以在远程分支的基础上分化出一个新的分支来：，在 fetch 操作下载好新的远程分支之后，你仍然无法在本地编辑该远程仓库中的分支。 $ git checkout -b branchName origin/branchName
2、跟踪远程分支
从远程分支 checkout 出来的本地分支，称为 跟踪分支 (tracking branch)。在跟踪分支里输入 git push，Git 会自行推断应该向哪个服务器的哪个分支推送数据。同样，在这些分支里运行 git pull 会获取所有远程索引，并把它们的数据都合并到本地分支中来。
3、删除远程分支
可以用这个非常无厘头的语法来删除它：git push [远程名] :[分支名]。
如果想在服务器上删除 serverfix 分支，运行下面的命令： $ git push origin :serverfix
3.6 Git 分支 - 分支的衍合 ：https://git-scm.com/book/zh/v1/Git-分支-分支的衍合
把一个分支中的修改整合到另一个分支的办法有两种：merge 和 rebase（译注：rebase 的翻译暂定为“衍合”，大家知道就可以了。）
1、基本的衍合操作
rebase 命令，可以把在一个分支里提交的改变移到另一个分支里重放一遍。
$ git checkout experiment
$ git rebase master
衍合能产生一个更为整洁的提交历史。
一般我们使用衍合的目的，是想要得到一个能在远程分支上干净应用的补丁 — 比如某些项目你不是维护者，但想帮点忙的话，最好用衍合：先在自己的一个分支里进行开发，当准备向主项目提交补丁的时候，根据最新的 origin/master 进行一次衍合操作然后再提交，这样维护者就不需要做任何整合工作（译注：实际上是把解决分支补丁同最新主干代码之间冲突的责任，化转为由提交补丁的人来解决。），只需根据你提供的仓库地址作一次快进合并，或者直接采纳你提交的补丁。
请注意，合并结果中最后一次提交所指向的快照，无论是通过衍合，还是三方合并，都会得到相同的快照内容，只不过提交历史不同罢了。衍合是按照每行的修改次序重演一遍修改，而合并是把最终结果合在一起。
2、有趣的衍合
需要用 git rebase 的 --onto 选项指定新的基底分支 master：
$ git rebase --onto master server client
现在可以快进 master 分支了：
$ git checkout master
$ git merge client
3、衍合的风险
要用它得遵守一条准则：
一旦分支中的提交对象发布到公共仓库，就千万不要对该分支进行衍合操作。
如果把衍合当成一种在推送之前清理提交历史的手段，而且仅仅衍合那些尚未公开的提交对象，就没问题。如果衍合那些已经公开的提交对象，并且已经有人基于这些提交对象开展了后续开发工作的话，就会出现叫人沮丧的麻烦。
2017-07-28 14:11，截止到这里，Git 在本地的常用知识已经结束，完全能满足日常开发使用。后续有时间，继续阅读。
# --name-only 只显示文件名
git log --name-only -1
# --pretty=format:"" 格式化commit message 这里什么都不显示
git log --pretty=format:"" -1
# 最终
git log --pretty=format:"" --name-only -1
#更实用：带有 sha-1 的提交指纹
git log --oneline --name-only -1