参考书籍：《git权威指南》
git初始化
设置git基本参数
通常会在用户home目录下创建文件".gitconfig"，以类似配置文件的格式来存放设置。
1、设置用户名及邮箱(在提交时会显示这些信息)
git config --global user.name "kcmetercec" git config --global user.email "kcmeter.cec@gmail.com"
2、git命令输出中打开颜色显示
git config --global color.ui true
3、git config 命令说明
当仅使用"git config"时，代表对当前版本库".git"下的"config"文件进行配置
当仅使用"git config --global"时，代表对当前用户home目录下的".gitconfig"文件进行配置
当仅使用"git config --system"时，代表对"etc"下的"gitconfig"文件进行配置
如同局部变量和全部变量一样，以上优先级由高到低。
格式为:git config [--global/--system] [section].[key] <value>
当没有<value>参数时，代表读取，反之则为写入。
版本库
1、创建版本库
使用创建版本库命令会在当前目录创建一个".git"文件夹，此文件夹既为版本库。而当前目录则称为工作区，
而后的工作就在工作区下进行操作了。
一般情况下，建议先创建好工作区文件夹后，再进入工作区文件夹进行版本库创建。
git init
#然后准备好工作区，并配置忽略表，进行第一次提交
#为版本库建立备份库
git clone --bare [repository] [directory.git]
#为备份库进行路径映射
#以后推送就可以git push name
git remote add <name> <url>
2、查找版本库及工作区
#显示版本库的位置 git rev-parse --git-dir #显示工作区根目录 git rev-parse --show-toplevel #显示当前目录相对于工作区的目录 git rev-parse --show-prefix #显示当前目录后退到工作区目录的深度 git rev-parse --show-cdup
git结构
git基本结构
如上图所示为git基本结构，对应上图做基本命令介绍。
工作区：用户实际操作文件的区域
index：暂存区，保存用户文件的信息结构，用于快速比对文件是否修改，类似于文件系统的inode
master:主分支，保存用户提交文件信息结构，用于快速比对文件是否提交，类似于文件系统的inode
HEAD：分支游标，用于表明当前正在操作那个分支
objects：对象库，用于实实在在存放文件内容的区域，类似于文件系统的block
#用于将工作区修改的内容保存到暂存区 git add [file]
#清除还没有加入版本库的文件及文件夹
git clean -fd #用于将工作区对应的文件撤回到和暂存区一样的状态， #也就是相对暂存区新做的修改都会删除 git checkout [file] #将暂存区所记录的文件修改都提交至代码库 git commit #将暂存区目录树替换为和HEAD指向的目录树一致，但工作区不受影响 git reset HEAD #删除暂存区的文件，工作区不受影响 git rm --cached [file] #将工作区以及暂存区的文件都恢复为和HEAD指向的分支一致 git checkout HEAD [file]
目录树浏览
1、浏览工作区目录树
使用经典的"ls"指令既可方便浏览
2、浏览暂存区目录树
#依次显示:对象属性 对象类型 对象ID 大小 名称 git ls-tree -l HEAD
3、浏览版本库目录树
#依次显示 对象属性 ID 暂存区编号 名称 git ls-files -s #要想与版本库显示效果一样需要 git write-tree git ls-tree -l [xxx] #xxx表示由"git write-tree"输出的ID值的至少前4位
相互比较
有以下辅助命令对上面3个区域进行差异状态查看：
#比较暂存区与工作区文件差异 git diff #比较工作区与版本库差异 git diff HEAD #比较暂存区与版本库的差异 git diff --cached #查看文件的提交状态 git status [-s]
git对象库
git中所有的对象都有一个ID，此ID用哈希值来表示独一无二的对象。
通过层层解码ID所对应的内容，最终就可以列出整个提交目录的结构以及用户文件的内容。
#-p 用于输出ID所对应的内容 #-t 用于输出ID对象的类型 git cat-file [-p/-t]
库的克隆
#以下方法将复制整个工作区及版本库到新的文件夹下 git clone [repository] [directory] #以下方法将仅仅复制版本库而不产生工作区 git clone --bare [repository] [directory.git] git clone --mirror [repository] [directory.git]
在对等工作区模式下，为了避免当前应用区“push”而导致备份区的工作区和版本库不一致，由备份区主动pull。
在克隆仅仅只有版本库情况下，可以在当前应用去使用push
git应用
git reset:重置分支
所谓的重置分支，就是调整分支引用游标，使其指向在历史提交。
但由于仅仅是移动了游标而不是真正删除了内容，所以依然可以在对象库中通过日志系统将其恢复到较新的提交。
注意：工作区中未add的内容将消失！
1、用于重置暂存区
git reset <-q> [<commit>] [--] [path].... #例如"git reset HEAD [paths]",相当于用当前HEAD 中[paths]状态替换掉暂存区中[paths]的状态
2、重置分支或暂存区
git reset [--soft | --mixed | --hard | --merge |--keep] [-q] [<commit>]
--hard:git reset --hard <commit>
*1.引用指向新提交ID
*2.暂存区和新引用指向目录树一致
*3.工作区的内容和新暂存区一致
--soft:git reset --soft <commit>
*1.引用指向新提交ID
--mixed:git reset --mixed <commit>
*1.引用指向新提交ID
*2.暂存区和新引用指向目录树一致
3、使用reflog挽救错误的重置
也就是将分支引用游标重新指向较新的提交。
#显示对于branch分支的所有日志，可以使用head命令限制输出
git reflog show branch
通过以上命令找到ID,再使用"git reset"命令恢复。
git checkout:检出
主要用于修改HEAD的指向。
1、替换工作区内容
#当省略commit，则由暂存区替换工作区的对应文件。指定后则为提交区替换暂存区和工作区的对应文件
git checkout [-q] [commit] [--] <paths>...
2、切换到分支
git check out [branch]
注意：当”branch“为当前分支的对象ID时，也就是将HEAD移动到了当前分支的以前提交。
那么HEAD就称为进入游离态，暂存区及工作区都会对应更新。如果这个时候更改了工作区并且提交，
那么就会生成一个隐性的分支，当将HEAD又切换到分支头时，且隐形分支有用时，
需要使用"git merge [ID number]"将这个分支合并。
3、切换到新分支
git checkout [-m] [[-b] --orphan] <new_branch> ] [<start_point>]
#切换HEAD到新branch,并且更新暂存区和工作区 git checkout branch #汇总显示工作区、暂存区与HEAD的差异 git checkout #用暂存区对应文件覆盖工作区中的文件 git checkout -- filename #用branch中的文件替换暂存区和工作区的对应文件 git checkout branch --filename #将暂存区所有内容都覆盖到工作区，也就是取消本地所有修改 git checkout .
git stash:保存及恢复
stash仅保存已经被库关联的文件。
#保存工作区及暂存区没有被提交的部分 git stash [save [--patch] [-k|--[no-]keep-index]] [-q|--quiet] [<message>] #为保存进度增加说明：git stash save "message.." #使用"-k"或"--keep-index"，在保存进度后不会重置暂存区 #显示有哪些进度被保存 git stash list #恢复保存的进度 git stash pop [--index] [<stash>] #当有"--index"，git除了恢复工作区，还会尝试恢复暂存区 #当有"stash"(进度名称)，git会恢复指定的stash #若没有后面两者，则默认恢复最新进度 #恢复进度后不删除进度列表 git stash apply [--index] [<stash>] #删除一个存储的进度 git stash drop [<stash>] #删除所有进度 git stash clear #以分支的方式恢复进度 git stash branch <branchname> <stash>
git rm:删除文件
删除文件的两种方式：
1、使用“git rm”从暂存区删除文件，然后使用"git commit"使改动生效
2、使用普通的"rm"指令删除文件，然后使用"git add -u"，将工作区改动记录到暂存区中，最后使用"git commit"使改动生效
恢复删除的文件
git checkout HEAD^ -- filename
git mv:移动（重命名）文件
移动文件方式：
git mv file1 file2 git commit -m "mv"
或者
mv file1 file2 git add -A git commit -m "mv"
git add -i :向导的方式添加文件
git tag:为当前版本建立标记
git tag -m "new tag message" tagname
.gitignore:文件忽略表
通过向.gitignore添加忽略文件列表，可以让git过滤掉很多干扰文件。
cat > .gitignore <<EOF #依次输入忽略文件名，可以使用通配符，最后输入"EOF"退出
最后，就仅有.gitignore会被标记为未版本控制，将此文件提交一次即可。
要将被忽略的文件显示出现，使用:
git status --ignored -s
也通过向.git/info/exclude添加忽略文件，则仅仅对本地库有忽略作用。
也可以通过命令"git config --global core.excludesfile filename",设置全局独享忽略列表。
忽略文件规则如下图：
git archive:文件打包
文件打包会默认把.git及忽略文件都排除在打包文件之外。
#将最新版本库打包 git archive -o latest.zip HEAD #仅打包src和doc目录 git archive -o partial.tar HEAD src doc #基于里程碑v1.0打包，并为打包中的文件添加目录前缀1.0 git archive --format=tar --prefix=1.0/v1.0 |gzip > foo-1.0.tar.gz
版本间操作：
git rev-parse:版本表示法
#显示当前分支 git rev-parse --symbolic --branches #显示标记 git rev-parse --symbolic --tags #显示定义的所有引用 git rev-parse --symbolic --glob=refs/* #显示HEAD哈希值 git rev-parse HEAD
git rev-list:版本范围表示法
#列出版本A开始的所有历史提交 git rev-list --oneline A #显示版本D和F开始的所有历史提交 git rev-list --oneline D F #排除D版本及其历史版本提交 #即使D历史版本也与F有关，既然也会排除 git rev-list --oneline ^D F git rev-list --oneline D..F #排除B和C能够共同访问的历史提交 git rev-list --oneline B...C #排除自身的历史提交 git rev-list --oneline B^@ #仅显示自身提交 git rev-list --oneline B^!
git log:浏览日志
#默认以HEAD显示日志,--oneline代表精简输出 git log [--oneline] #分支图显示 git log --graph [--oneline] #显示最近3条日志 git log -3 #显示每次提交的具体改动 git log -p #显示变更概要 git log --stat [--oneline ] #显示提交树ID git log --pretty=raw #显示作者和提交者 git log --pretty=fuller #显示D分支提交 git show D --stat git cat-file -p D^0
git diff:差异比较
#比较标记B和A git diff B A #比较工作区和标记A git diff A #比较暂存区和标记A git diff --cached A #比较工作区和暂存区 git diff #比较暂存区和HEAD git diff --cached #比较工作区和HEAD git diff HEAD #比较文件不能版本差异 git diff <commit1> <commit2> -- <paths> #任意比较两个文件 git diff <path1> <path2> #逐词比较 git diff --word-diff
git blame:文件追溯
#追溯文件
git blame filename
#追溯第n行开始的向下m行
git blame -L n,+m filename
git bisect:二分查找
当发现版本有BUG时，二分查找用于通过不断比对找出BUG开始哪个版本。
注意：在使用二分查找前，必须将工作区提交或者撤销修改。
使用步骤：
1、选定一个分支：git checkout master
2、开始查找:git bisect start
3、将当前版本标记为坏提交:git bisect bad
选定一个版本标记为好提交:git bisect good
此时，git会自动切换版本到好提交和坏提交之间的一个版本
4、检查当前版本是否有BUG，有BUG则再次定义为坏提交，无BUG则定义为好提交。git又会自动切换。
5、重复步骤4，最终定位的坏提交引用refs/bisect/bad标识，然后切换过去：git checkout bisect/bad
6、当修复bug后，撤销二分查找：git bisect reset，git会自动切换回二分查找之前的版本库
当好版本和坏版本标记错误时：
#1、保存二分查找日志到文件 git bisect log > logfile #2、删除日志文件记录错误的行 #3、结束当前二分查找 git bisect reset #4、通过日志恢复进度 git bisect replay logfile #5、重新标记
自动化二分查找
可以将查找命令写入脚本文件，自动检测出BUG版本。
若脚本退出码是0，则代表好版本。
若脚本退出码是125，则代表跳过此版本
若脚本退出码是1~127(125除外)，则代表为坏版本。
使用步骤如下：
1、编写查询BUG版本
2、规定好版本和坏版本范围：git bisect start [commit 1] [commit2]
3、启动自动化测试: git bisect run sh file.sh
4、最终定位的坏提交引用refs/bisect/bad标识，然后切换过去：git checkout bisect/bad
5、当修复bug后，撤销二分查找：git bisect reset，git会自动切换回二分查找之前的版本库
获取历史版本
对历史操作
对历史的操作也仅仅是看起来改变了历史，实际上所有的一切依然都记录在日志中，
在本质上也是一个新提交而已。
重新修改上次提交说明
git commit --amend -m "msg"
将多个历史提交修改为一个
1、使用git reset --soft HEAD^n 回滚n个提交，（此回滚仅仅移动引用，暂存区和工作区不变）
2、使用git commit -m "msg"合并n个提交
git tag:创建标记
显示标记
#显示当前版本库的标记列表 git tag -n<num>#<num>代表每个tag说明最多显示num行 #显示当前分支下的标记及详情 git log <--oneline> --decorate
git describe <--dirty> #以易读的方式显示当前版本提交名称 #若当前提交没有标记，则显示<tag>-<num>-g<commit> #代表相对于<tag>的第<num>次提交，提交简易ID为<commit> #当加上--dirty时，若工作区有改变，会在名称后面加上"-dirty"
git name-rev [commitID] <--tags>
#显示对于commitID的引用，若加上--tags，则引用名优先使用标记名
创建标记
#创建轻量级标记 git tag [name] <commit> #创建带说明的标记 git tag -a [name] <commit> git tag -m [msg] [name] <commit> #创建带GnuPG签名的标记 git tag -s [name] <commit> git tag -u [key-id] [name] <commit>
删除标记
git tag -d [tagname]