Git(二):版本回退及分支

关于Git版本控制更加深入一点的知识，详细初始使用请查看上一篇：关于Git的配置使用及常见问题
本文主要包括版本回退及分支相关内容。

版本回退

• git reset --hard HEAD^回退到上一版本
• git reset --hard HEAD^回退到上上版本
• git reset --hard HEAD~100回退到上100个版本
• git reset --hard 具体版本号回退到具体版本号
  记录每一次命令：git reflog
git checkout -- readme.txt：
  命令git checkout -- readme.txt意思就是，把readme.txt文件在工作区的修改全部撤销，这里有两种情况：
  一种是readme.txt自修改后还没有被放到暂存区，现在，撤销修改就回到和版本库一模一样的状态；
  一种是readme.txt已经添加到暂存区后，又作了修改，现在，撤销修改就回到添加到暂存区后的状态。
  总之，就是让这个文件回到最近一次git commit或git add时的状态。

删除

删除文件后，Git知道你删除了文件，因此，工作区和版本库就不一致了，git status命令会立刻告诉你哪些文件被删除了：
现在你有两个选择，一是确实要从版本库中删除该文件，那就用命令git rm filename 删掉，并且git commit
另一种情况是删错了，因为版本库里还有呢，所以可以很轻松地把误删的文件恢复到最新版本： git checkout -- filename

分支

• git branch 分支名：创建分支
• git checkout 分支名：切换分支
• git checkout -b 分支名 ：创建与切换同时进行
• git branch：列出所有分支
• git merge dev：把dev分支的工作成果合并到master分支上
• git branch -d 分支名 : 删除分支

分支策略

在实际开发中，我们应该按照几个基本原则进行分支管理：
首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；
那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；
你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。
所以，团队合作的分支看起来就像这样：

多人协助

本文作者：rottengeek
原文链接：https://segmentfault.com/a/1190000016012022