装逼

1.文件在各个区域的状态

工作区

主流程

git add

git commit

对于直接添加进git仓库而没有进行管理的文件，执行git status会提示:untracked files

未跟踪的文件

说明git已经检测到文件了，但是没有进行跟踪，此时需要纳入到git管理中，执行git add命令，可以只选个其中若干文件，git add file,或者一次性全部加进来，git add .

可以把`add`指令理解为加入购物车

已纳入版本管理

此时的文件已经可以进行提交了,使用git commit -sm '此次变更的总结'。当然如果反悔了也可以根据git的提示，进行git reset HEAD <file>。文件又会回到未跟踪状态。

不幸的是，Microsoft的Word格式是二进制格式，因此，版本控制系统是没法跟踪Word文件的改动的，

二进制文件无法对比变更

所以文章开头的图只能装逼，如果要真正使用版本控制系统，就要以纯文本方式编写文件。

2.编辑已经提交的commit

如果刚不小心写错了commit信息，可以使用git commit --amend
会默认打开编辑器，修改commit信息后:wq即可
如果在上次漏掉一个文件后，也可以修改后先git add <file>再执行此命令，将此次修改合并到上一次commit

3.版本回退

我们执行的每一次命令，git都会有记录，git reflog可以查看操作历史。其中
HEAD指向的版本就是当前指向的版本，使用命令git reset --hard commit_id。
注意参数--hard ，重置HEAD并且丢弃本地未提交的变更，--soft则会在重置HEAD的同时保留未提交的变更。
穿梭前，用git log可以查看提交历史，以便确定要回退到哪个版本。
要重返未来，用git reflog查看命令历史，以便确定要回到未来的哪个版本。
该git reflog用来记录你的每一次命令

git reflog

4.分支管理

git-model@2x.png

【git merge】

默认分支

dev分支

新建分支并提交

0-3.png

fast-foward

注意到上面的Fast-forward信息，Git告诉我们，这次合并是“快进模式”，也就是直接把master指向dev的当前提交，当然我也可以保留此次合并，所以我们通过强制git产生一个真正的merge---通过使用--no-ff参数（no fast forward的意思）

【git rebase vs git merge】

两种用法：
1）针对一些本地提交进行重新编辑，合并commit。

整合commit

2）在合并代码时进行变基操作，使得提交历史线性直观。

737565-20160407213124718-1899357504.png

737565-20160407213427281-1160492709.png

其他一些补充

git cherry-pick : 将一个已经存在的commit应用到其他分支上
git stash:暂存当前工作区的内容
git config --global alias.me 'merge'
git log --oneline -5
git revert