创建一个版本库（repository）
$ git init #将该目录变成Git可以管理的仓库，该目录下，多一个.git目录
代码提交
$ git add readme.txt ` #将文件放到stage中
$ git commit -m 'wrote a readme file' # 提交到分枝
查看信息
$ git status # 仓库当前的状态
$ git diff # 查看修改的内容
$ git log # 查看提交历史，以便确定要回退到哪个版本
$ git reflog # 查看命令历史，以便确定要回到未来的哪个版本。
版本返回
$ git reset --hard HEAD^ 返回上一个版本
$ git reset --hard 3628164 返回指定的版本
丢弃修改
$ git checkout -- readme.txt 丢弃工作区的修改
$ git reset HEAD readme.txt 暂存区的修改撤销掉（unstage），重新放回工作区
$ git rm test.txt 从版本库中删除该文件
$ rm test.txt 从工作区删文件
远程库
git remote add origin git@server-name:path/repo-name.git 要关联一个远程库
git push -u origin master 第一次推送master分支的所有内容；
git push origin master 推送最新修改；
$ git clone git@github.com:michaelliao/gitskills.git 克隆一个本地库
分枝
$ git checkout -b dev 创建并切换
git branch命令查看当前分枝
$ git merge dev 分枝合并到master
git branch -d <name> 删除分支
git log --graph命令可以看到分支合并图
$ git merge --no-ff -m "merge with no-ff" dev 注意--no-ff参数，表示禁用Fast forward
分支策略
在实际开发中，我们应该按照几个基本原则进行分支管理：
首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；
那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；
你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。
所以，团队合作的分支看起来就像这样：
git-br-policy
bug分枝
修复bug时，我们会通过创建新的bug分支进行修复，然后合并，最后删除；
当手头工作没有完成时，先把工作现场git stash一下，然后去修复bug，修复后，再git stash pop，回到工作现场
