第一次看这本书，是在两年以前了，最近又看了一遍，发现好多东西已经忘记了，另外，在最近两年的工作中，有些很有用的命令我居然一次都没用过， 所以，为以后查阅方便和更有效率的工作，写一篇笔记吧。
一、概述
版本库和工作目录树：
1、使用Git相关命令初始化版本库，即生成“.git”目录，于是，“.git”目录的父目录就是工作目录树
2、克隆（clone）一个已有的版本库，也就连带创建了工作目录树
Git安装完成之后，配置相关参数：
--global参数代表配置的是全局参数
git config --global user.name “hwgt”
git config --global user.email “[email protected]”
设置完成之后，可用下列命令检查参数是否设置成功：
git config --global --list
仅以上两个全局参数是必须设置的，另外，比较常用的有：
若想在命令行窗口使用不同的颜色显示不同类型的内容，可以将“color.ui”设置为“auto”或“always”：
git config --global color.ui “auto”
若想简化Git命令的书写，可以使用git config --global
alias.aaa “commit”，
意为将git commit 简写为git aaa，只需用简写别名替换alias后边的部分就可以了
Git的图形界面：
使用命令git gui可以启动Git图形界面，基本上的Git命令都可以在图形界面中完成（相关内容本文略）
使用gitk查看历史信息：
键入命令gitk就可以启动gitk，加入参数--all就可以显示全部分支的历史信息
获取Git的帮助信息：
通过命令行 git help <command>（用希望了解的具体命令名称替代<command>），显示Git手册中某个命令的描述
二、具体使用
创建版本库：
mkdir myfolder 创建文件夹
cd myfolder 进入文件夹
git init 创建一个版本库，即“.git”目录，该目录用来存放版本库的全部元数据，而myfolder 目录作为工作目录树，用来存放从版本库检出的代码
或者clone一个已有的版本库：
git clone ，该命令有两个参数，远程版本库的位置和存放该版本库的本地目录，第二个参数不指定的话，则为当前目录
添加文件到索引（暂存区）：
git add myfile.java
除了简单的使用add来添加文件外，还可以使用Git交互添加方式（使用不同的参数来指定不同的添加方式）来选择要暂存的文件的部分内容，使用-i选项可以启动该方式。
添加或修改文件之后，使用命令 git add -i ，Git给出如下提示（下图截取自《版本控制之道—使用Git》一书）：
有几个选项可供选择：
A、输入1，显示与该方式启动时相同的输出
B、想要添加文件到暂存区，可以输入2，显示可暂存文件列表，接着输入文件对应的序号，如果输出结果中，文件名称前出现星号（*）标识，表示文件已被暂存
C、如果想要取消已暂存的修改，可以输入3，用法同update
D、如果想要暂存还没有被Git跟踪的文件，可以输入4，用法同update
E、patch模式是交互方式中最有用的模式，进入“patch”模式后，可以选择单个或多个文件，选择后，Git会显示这些文件的当前内容和版本库中的差异，然后据此决定是否添加这些修改到暂存区。运行情况如下（下图截取自《版本控制之道—使用Git》一书）：
根据提示，y表示接受修改，n表示忽略修改，a和d分别表示添加和放弃剩余修改，输入？将显示所有选项的帮助信息
另外，使用git add -p 命令就可以直接进入补丁模式：
F、输入7，退出交互方式
查看工作目录树状态—git
status：
Git中有三个地方可以存放代码，第一个是工作目录树，我们直接编辑文件的地方，第二个是索引（index），也就是暂存区，暂存区是工作目录树和版本库之间的缓冲区，这里存放着打算提交到版本库的变更。第三个是版本库。
当对myfile.java文件进行了修改，执行git status，结果为
Changed but not updated，如要提交，需先做暂存操作，即git add，执行暂存操作过后，再执行git status，结果为Changes to be commited
要查看更改详情—git diff：
使用git diff 命令，Git可以显示工作目录树、暂存区和版本库之间的区别。
使用不带参数的git diff 命令，显示工作目录树中未被暂存的改动
git diff --cached 命令可以显示暂存区和版本库中的区别，当然这个命令不会显示未被暂存的修改
git diff HEAD 命令可以显示工作目录树（包括已暂存和未暂存）和版本库的区别
文件的重命名—git mv：
git mv A.java B.java
创建分支：
git branch RB_1.0 在当前分支末梢创建RB_1.0 分支
git branch RB_1.0 master 命令用来在主分支（master）上创建一个RB_1.0 分支，RB_1.0 中的RB代表发布分支（release
branch）
git branch RB_1.0.1 1.0 在标签（1.0）上创建一个RB_1.0.1
分支
git branch 命令显示本地版本库中的所有分支名称
分支重命名：
git branch -m RB_1.0
HWGT_RB_1.0
参数-m不会覆盖已有分支名称，所以新名称（第二个参数）必须是唯一的，否则会报如下提示（下图截取自《版本控制之道—使用Git》一书）：
将“-m”改为“-M”则强制覆盖
切换分支：
git checkout RB_1.0 ，代表切换到RB_1.0 分支
创建和检出分支的快捷方式：
git checkout -b RB_1.0 master ，在主分支（master）上创建一个RB_1.0 分支，并且检出RB_1.0 分支
变基：
变基是指 把一条分支上的修改在另一条分支末梢重现，假设当前是在master分支上，master和RB_1.0 分支的分叉点是版本1.0，如：
git rebase RB_1.0 ，Git会把从版本1.0到master分支当前末梢之间的所有提交，顺序加到分支RB_1.0
末梢上去，生成新的master分支及其末梢，而分支RB_1.0 及其末梢则没有任何变化。
删除分支：
git branch -d RB_1.0
只有当要删除的分支已经成功合并到当前分支上时，删除操作才会成功，否则会报如下提示信息（下图截取自《版本控制之道—使用Git》一书）：
如无需合并，则将“-d”改为“-D”强制删除
合并分支间的修改：
分支间共享修改是由分支的合并（merge）来实现的，主要有三种合并方式：
A、直接合并，如果想把一条分支上的全部历史提交合并到另一条分支上，可以采取这种方式，步骤为：
首先，切换到合并操作的目标分支
然后，使用git merge命令指定想要合并到当前分支的源分支名称，如： git
merge ABC，这样ABC分支就合并到当前分支上了
B、压合合并，指的是Git将一条分支上的所有历史提交压合成一个提交，提交到另一条分支上。一条分支上的所有提交都密切相关，最后需要作为一个整体记录的情况下，适合采用压合合并。
如当前在分支ABC上，做了两次commit，现需要将这两次commit压合成主分支上的一个提交，则：
首先，切换到主分支
然后，使用命令 git merge --squash
ABC，将ABC分支的所有提交压合成主分支的一个提交
最后，使用git commit 提交压合成的这个提交
C、拣选合并，当分支间只需要合并一个提交时使用，使用git cherry - pick 命令可以合并单个提交
如当前在分支ABC上，做了多次commit，现需将下图（截取自《版本控制之道—使用Git》一书）所示的commit添加到主分支的末梢，
则：
首先，切换到主分支
然后，根据提交名称对它进行拣选操作（下图截取自《版本控制之道—使用Git》一书）：
当需要拣选多个提交时，需给git cherry - pick 命令传递参数-n，告诉Git在创建提交前需要进行连续的合并操作，步骤如下：
连续执行git cherry - pick -n 321d76f（在执行该命令期间，改动会被暂存，等待提交），拣选完毕之后，再使用git commit 一并提交，注意，此时不用-m参数，编辑器会利用被拣选的提交的留言作为现在的提交留言。
冲突处理：
不同的分支对同一文件的同一文本块进行不同的修改并试图合并时，就会产生冲突（conflict）。此时，需要人工介入进行修改。
提交修改：
这里的提交是指将暂存区的修改提交到本地版本库而不是某个中央版本库，以下是三种常用的提交方式：
A、提交暂存后的修改
git commit -m “add myfile.java”\
-m “hahahhahahahahha”
参数-m之后的是提交留言，这里使用了两个-m，Git可以接受任意多次提交留言，每次另起一段。
B、提交工作目录树中的所有修改
git commit -m “add myfile.java” -a
-a参数代表提交全部修改过的文件，这种情况下，Git只会把已跟踪的文件纳入版本库中，而不会添加尚未被跟踪的文件
C、提交工作目录树中指定的修改
git commit -m “add myfile.java”
myfile
三种方式的区别是：A是先暂存后提交，B和C是直接提交，B是提交所有，C则提交指定部分
处理发布，打标签：
git tag 1.0 RB_1.0
两个参数分别代表标签名称和希望打标签的点（RB_1.0 分支的末梢）
查看标签列表：
git tag
查看Git历史记录：
对历史的记录和管理是Git的关键功能，在Git中添加和修改文件都会以提交为单位记录下来，形成历史。
A、查看Git 日志
不带参数的git log命令运行后的显示结果，
第一行为提交的名称，为自动产生且是独一无二的，Git通过它来跟踪提交，其前7位和git commit命令输出的相同。
第二行是提交者的信息，第三行是提交日期，最后是提交留言
git log -p显示版本间的代码差异
git log -1可以通过改变数字1来限制git log 命令输出的提交条目的个数。
也可给git log命令传递一个版本作为查看日志的起始点，如（下图截取自《版本控制之道—使用Git》一书）：
B、指定查找范围
git log --since=“5 hours” 查看5小时内的提交
git log --before=“5 hours” -1 查看5小时之前最后一个提交
Git能够识别诸如--since=“12 hours”、--since=“1
minute”、--before=“2008-10.01”这样的日期格式
也可查找两个版本之间的提交，如（下图截取自《版本控制之道—使用Git》一书）：
老版本在前，新版本在后，含尾不含头
设置版本范围时，可用HEAD代表当前分支末梢的最新版本，不输入HEAD则默认有HEAD。
也可使用标签名称进行查找，如（下图截取自《版本控制之道—使用Git》一书）：
上图中git log命令之后的参数--pretty，format：“%h %s”告诉Git显示提交名称的缩写和提交留言的第一行
C、查看版本之间的差异
比如，查看ABC这个版本和当前工作目录树之间的差异：git diff ABC
git diff 指定查找范围的方法和git log 一样，只不过git diff 显示的是最新版本与最老版本之间的差异
D、查明该向谁问责
使用git blame命令，查看具体提交信息
传递参数-L可以缩小查找范围，如：
E、跟踪内容
F、撤销修改
使用git revert命令，Git立即提交撤销结果，也可以增加参数-n执行多个revert命令，Git会暂存多个撤销操作，然后一次性提交，如：
与远程版本库的协作：
git stash的使用：
git stash 用来暂存当前正在进行的工作，比如当前分支的开发工作未完成，却又要切换到另外一个分支进行开发的时候，除了commit原分支的代码，git
stash也是一个不错的选择。
git stash pop 命令则被用来恢复已被暂存的最新的改动。
当多次使用git
stash 命令之后，可以使用git stash list 查看stash队列。然后使用命令git stash pop [email protected]{id}或者 git
stash apply [email protected]{id}恢复指定的被暂存的工作。
git stash pop [email protected]{id}和 git
stash apply [email protected]{id}的区别是：使用git stash pop命令，恢复被暂存的工作的同时会将stash队列中对应的stash删除。而使用git stash
apply命令， 除了不在stash队列删除外其他和git stash pop 完全一样。
git stash drop <[email protected]{id}> 如果不加stash编号，就是删除最新的，加编号就是删除指定编号的stash。
git
stash clear 是清除所有stash。
未完待续 ... ...