创建一个版本库（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，回到工作现场