github review <1>

github review 系列主要是因为要向github提交leetcode代码，但是之前看的《git权威指南》因为好久没用所以给搁置了，捡起来review一下O(∩_∩)O哈！

---

common comand:

• git add
• git ci -m ‘description’
• git st -s -s是short的意思
• git log –oneline –graph
• git diff 工作区和暂存区(stage)的差异

.git/index 实际上就是一个包含文件索引的目录树，像是一个虚拟的工作去。文件的内容保存在.git/objects对象库目录中。

---

工作区、版本库、暂存区原理图

1. 上图左侧为工作区,右侧为版本库。在版本库中标记为index的为暂存区，标记为master的是master分支所代表的目录树。
2. 对工作区的修改执行git add时，暂存区的目录树会更新，同时文件内容会被写入到对象库中的一个新的对象中，而该对象的ID被记录在暂存区的文件索引中。
3. git commit命令时，暂存区的目录树会写入到版本库中。master分支会相应的更新。即master最新指向的目录树就是提交时原暂存区的目录树。
4. git reset HEAD，暂存区的目录树会被重写，会被master分支所指向的目录树所替换，但是工作区不受影响。
5. git rm –cache < file> 的时候，会从暂存区删除文件，工作区不受影响。
6. git checkout . 或者 git checkout – < file> 的时候，会用暂存区全部的文件或者指定的文件替换工作区的文件。这个操作很危险，会清除工作区未添加到暂存区的改动。
7. git checkout HEAD . 或者 git checkout HEAD < file>命令时，会用HEAD指向的master分支中的全部或者部分文件替换暂存区和工作区中的文件。

git diff 命令

1. 比较工作区和暂存区 git diff
2. 比较暂存区和HEAD git diff –cache
3. 工作区和HEAD比较 git diff HEAD

---

对象库

git cat-file
-t参数 后面跟对象id 显示类型
-p参数 显示对象详细信息

git rev-parse master
显示对象ID

分支的实现：
master为例，master分支在版本库的引用目录中 （.git/refs）体现为一个引用文件.git/refs/heads/master，起内容就是分支中最新提交的提交ID

---

git reset重置

用法一：git reset [-q] [< commit>] [–] < paths>… 为了避免路径和引用（或提交ID）同名而发生冲突，可以在< paths>前用–作为分隔
用法二：git reset [–soft | –mixed | –hard | –merge | –keep] [-q] [< commit>]

git reset省略commit就是默认HEAD。

1. 第一种用法不会重置引用，更不会更改工作区，只是用指定commit下的文件替换掉暂存区中的文件。用法举例：
   git reset HEAD < paths>取消之前执行的git add < paths>命令时改变的暂存区。
2. 第二种用法则会重置引用(master引用)。
   
   • 参数–hard
     
     1. 改变master(或者其他分支)引用
     2. 用commit指向的目录树替换暂存区
     3. 替换工作区，使得和暂存区一样
   • 参数–soft
     只改变当前分支的引用
   • 参数–mixed(默认参数)
     
     1. 改变当前分支的引用
     2. 改变暂存区，不改变工作区

实例：

• git reset
  用HEAD指向目录树重置暂存区。
• git reset HEAD
  同上
• git reset – filename
  文件filename的改动撤出暂存区，其它文件不变。
• git reset HEAD filename
  同上
• git reset –soft HEAD^
  撤销最近的提交以便重新提交。

重置反悔

1. git reset –hard HEAD^
   重置到HEAD的父提交
2. git reflog show master | head -5
   输出中，这里< refname>@{< n>}含义是引用< rfname>之前第< n>次改变时的SHA1哈希值。
   用来挽救错误的重置
   接着命令是
3. git reset –hard master@{2}

---

git checkout检出

git merge commitID 会将commit合并到当前分支中。

用法一：git checkout [-q] [\] [–] < paths>… 为避免路径和引用（或提交ID）同名而发生冲突，可以在< paths>前用–作为分隔

此用法不会改变HEAD头指针，主要用于指定版本的文件覆盖工作区中对应的文件。若省略< commit>，则会用暂存区的文件覆盖工作区的文件，否则用指定提交中的文件覆盖暂存区和工作区中对应的文件。

用法二：git checkout [< branch>]

此用法会改变HEAD头指针，之所以后面的参数写作< branch>，是因为只有HEAD切换到一个分支才可以对提交进行跟踪，否则仍然会进入“分离头指针”的状态，此状态下提交不能被引用关联到，从而可能丢失。所以此用法最主要的作用就是切换到分支，若省略则相当于对工作区进行状态检查。

用法三：git checkout [-m] [[-b | orphan] < new_branch>] [< start_point>]

此用法主要是创建和切换到新的分支，新的分支从< start_point>指定的提交开始创建。新分支与master分支没什么实质的不同，都是在refs/heads命名空间下的引用。

用法举例

• git checkout branch
  更新HEAD指向branch分支，并用branch指向的
• git checkout
  汇总显示工作区、暂存区和HEAD的差异。
• git checkout HEAD
  同上
• git checkout – filename
  用暂存区的filename来覆盖工作区的filename。
• git checkout branch –filename
  HEAD不变，用branch指向的提交中的filename替换暂存区和工作区中的文件。
• git checkout – .或者git checkout .
  会取消所有本地的修改（相对暂存区）相当于用暂存区覆盖工作区。