1. fast-forward和non fast-forward分别代表什么概念？
2. 在git中文件index是个什么概念？
3. stage/index/cache三者有什么关系？
4. git hard/soft/mix是什么概念？
5. HEAD
6. HEAD~和HEAD^
7. git rebase -i/git rebase origin/master
1. fast-forward和non fast-forward分别代表什么概念
fast forward是指可以通过HEAD指针的简单移动就可以达到合并的效果，而后者则反之。比如master分支上新建了一个dev指针，并且在master和dev上都有提交，但是二者并不是涉及同一行，也即没有conflict，这样在master分支上合并dev或者dev分支上合并master都会提示为此次的merge为fast forward, 只是HEAD指针的简单前移。
non-fast forward则可以理解为A和B同时从server更新了同一份代码，而A更改某个文件后提交，随后B也更改了该文件，当执行git push的时候，则会提示non fast forward, 这个时候需要git pull更新，然后提交。
所以只要是server上的master向前进了，而本地branch是master以前的基线，在push的时候就会non-fast，所以要像svn一样，先git pull进行合并更新(update)，然后在push到server上。
2. 在git中文件index是个什么概念？
索引文件index：http://www.360doc.com/content/12/0419/17/1016783_204960412.shtml
理解下来，git add会把“工作目录”中的改变写到“index file”中，而git commit会把“index file”中的改变写到“git 仓库”。commit -a会直接把“工作目录”的改动写到“index file”和“git 仓库”.
git diff其实就是workcopy本地的内容和index文件比较，而不是和提交的HEAD比较，所以当本地执行完git add后，再git diff会是空的。如果想和HEAD比较，需要git diff HEAD.
那这个index文件存在哪呢？.git/index中二进制文件就是。下图可以看三者的关系：
3. stage/index/cache三者有什么关系？
git术语解释：http://blogread.cn/it/article/7581
可以理解为index是文件提交的暂存区名称，而暂存区的这些文件前缀都是"cache", 所以现在用cached来形容的命令，表示要操作的文件是存在于index中，而不是workcopy中。而staged和cached更像是同义词，也是git后面版本使用的名词。
4. git hard/soft/mix是什么概念？
首先，hard/soft/mix这三个名词只是用在git reset下;其次，reset的作用是重置HEAD指针到另外一个commit。比如git reset HEAD那什么事情也不会发生。
--soft, 只是将HEAD指针变更，而之前的original HEAD和current HEAD之间的变更内容都放在stage(index)中。
--hard, HEAD指针变更，同样重置index和workcopy，使得三者完全匹配，这是比较危险的，因为这会使得你丢掉work tree.
--mixed(default), 如果git reset不跟参数，那这个是默认，新的HEAD和index匹配，但是workcopy不会被修改，而是把original HEAD和current HEAD之间的变更保存到working copy中作为本地未提交、为stage的内容，用户可以重新修改，然后做commit。
5. HEAD
HEAD:当前分支的最近一次提交；
6. HEAD~和HEAD^
看上去挺复杂：http://mux.alimama.com/posts/799
7. 为了git tree保持整洁，在server的master有更新后，可以执行以下
- git fetch origin/master
- git rebase origin/master
- git push
那么这和git rebase -i有什么不同，-i是指交互，意识是你可以在rebase过程中干涉这件事情，如edit/pick等，那git rebase origin/master不可以吗？
如果是本地两个分支，1个master，1个dev, dev是在master基线上branch出来的。 dev之后向后走了2个提交，master走了1个，而用户想把dev两个提交进行rebase，那么用户可以，git checkout dev->git rebase -i master->解决冲突->git add .->git commit ->git rebase --continue->修改->结束rebase->git checkout master->git merge dev这样二者就都保持最新了。