Pro Git --- 读书笔记 （Chaptero4）

交互式暂存

git add -i

• 进入交互式终端，输入相应指令，可以暂存文件、取消暂存文件、暂存文件的一部分、添加未被追踪的文件、显示暂存内容的区别

贮藏与清理

• git stash指令会处理工作目录的脏状态，即跟踪文件的修改与暂存的改动，然后将未完成的修改保存到一个栈上，而你可以在任何时候重新应用这些改动（甚至在不同的分支上）

• 查看贮藏的信息

git stash list

• 将刚刚贮藏的工作重新应用

git stash apply

• 应用一个更加旧的贮藏

git stash apply stash@{<num>}

• 但是之前暂存的文件没有重新暂存，这时候需要在指令后面加入--index

• 应用选项只是还原，但是stash上还有它，需要手动删除

git stash drop stash@{<num>}

• 也可以应用并丢弃

git stash pop

• 默认是不会贮藏未跟踪文件，需要加上--include-untracked或-u选项

• 从贮藏创建一个分支，会应用成功后丢弃贮藏

git stash branch <branch>

修改最后一次提交

git commit --amend

• 修正会改变提交的校验和，类似于一个小的变基，如果已经推送了，那么就不要修正了

重置揭密

• 以Git的思维框架来管理三棵不同的树

树	用途
HEAD	上一次提交的快照，下一次提交的父结点
INDEX	预期的下一次提交的快照
Working Directory	沙盒

• HEAD是当前分支引用的指针，它总是指向该分支上的最后一次提交
• INDEX是预期的下一次提交，可以将该概念引用为Git的“暂存区”
• 工作目录或者工作区。另外两棵树以一种高效但并不直观的方式，将它们的内容存储在.git文件夹中，工作目录会将它们解包为实际的文件以便编辑，可以把工作目录当作沙盒，在将修改提交到暂存区并记录到历史之前，可以随意修改

重置的作用

• 重置之前
  

1. 移动HEAD，reset做的第一件事是移动HEAD的指向，这与改变HEAD自身不同（这是checkout所做的），reset移动HEAD指向的分支，这意味着如果HEAD设置为master分支，运行git reset 9e5e6a4这会使master指向9e5e6a4

无论调用哪一种形式的带有一个提交的reset，首先都会尝试这样做，使用--soft，它将仅仅停在那儿
这个本质上是撤销了上一次git commit指令，当reset回来时，其实就是把该分支移动回原来的位置，而不会改变索引和工作目录，现在可以更新索引并再次git commit来完成git commit --amend所要做的事情了

2. 更新索引（--mixed），接下来reset将会用HEAD指向的当前快照更新索引

如果指定--mixed选项，这也是默认选项，那么reset会停留在这里；所以这个阶段发生的事情是，会撤销上一次提交，然后取消暂存的所有的东西，于是，这相当于我们会回滚到git commit和git add之前

3. 更新工作目录(--hard)，reset要做的第三件事就是让工作目录看起来像索引

现在，reset会撤销提交、撤销add、撤销修改

通过路径重置

当指定reset的作用路径之后，它将会跳过第一步，并且将它的作用范围限定为指定的文件或文件集合。因为HEAD只是一个指针，无法让它同时指向两个提交中的各自一部分。不过索引和工作目录可以部分更新，所以重置可以继续2、3步

git reset xxx.txt
等价于
git reset --mixed HEAD xxx.txt

• 该指令将会移动HEAD分支的指向（已跳过），让索引看起来像HEAD，所以它本质上只是将xxx.txt从HEAD复制到索引中，其实就是取消暂存文件的效果

我们也可以指定具体的一个提交来拉取该文件的对应版本

git reset eb43bf xxx.txt

检出（checkout）

该命令于reset之间的区别，在于是否给该命令传递一个文件路径

不带路径

git checkout <branch>
git reset --hard <branch>

• 这两个命令的效果非常相似，都会更新所有的三棵树使其和某branch一样
  1. 首先，于reset不同，checkout对工作目录是安全的，它会通过检查来确保不会将已更改的文件弄丢。
  2. 还有就是，checkout只会移动HEAD自身来指向另一个分支

带路径

当指令带文件路径，效果和reset一样不会移动HEAD

git reset --hard <branch> file
git checkout file

• 索引和工作目录的指定文件都会更新为特定版本，但是HEAD不会移动

数据恢复

在reset --hard指令下，可以将HEAD回退到旧的提交中，而之前的提交就没有其他的分支指向了，变成了游离的提交

• git reflog指令，当在工作中，Git会默默地记录每一次你改变HEAD时的值，每一次改变分支或者提交时，reflog都会被更新
• 或者git log -g指令，可以更加详细地查看到reflog
• 当得知游离的那个commit-hash之后，就可以创建一个分支来指向这个commit

git branch <branch> <commit>

• 还有一种情况，当因为某种原因，reflog没有了这些记录，那需要别的工具来寻找那个丢失的commit
• git fsck工具，这将会检查数据库的完整性，当加上--full选项之后，将会显示出所有没有被其他对象指向的对象（"dangling commit"就是丢失的那个提交）