Add 2.5 检出之前的提交.

sources/检出以前的提交.md

@@ -0,0 +1,101 @@
+## 检出之前的提交
+
+> BY 童仲毅([geeeeeeeeek@github](https://github.com/geeeeeeeeek/git-recipes/))
+> 
+> 这是一篇在[原文(BY atlassian)](https://www.atlassian.com/git/tutorials/viewing-old-commits)基础上演绎的译文。除非另行注明，页面上所有内容采用知识共享-署名([CC BY 2.5 AU](http://creativecommons.org/licenses/by/2.5/au/deed.zh))协议共享。
+
+## git checkout
+
+`git checkout`这个命令有三个不同的作用：检出文件、检出提交和检出分支。在这一章中，我们只关心前两种用法。
+
+检出提交会使工作目录和这个提交完全匹配。你可以用它来查看项目之前的状态，而不改变当前的状态。检出文件使你能够查看某个特定文件的旧版本，而工作目录中剩下的文件不变。
+
+### 用法
+
+``` 
+git checkout master
+```
+
+回到master分支。分支会在下一节中讲到，而现在，你只需要将它视为回到项目『当前』状态的一种方式。
+
+``` 
+git checkout <commit> <file>
+```
+
+查看文件之前的版本。它将工作目录中的`<file>`文件变成`<commit>`中那个文件的拷贝，并将它加入缓存区。
+
+``` 
+git checkout <commit>
+```
+
+更新工作目录中的所有文件，使得和某个特定提交中的文件一致。你可以将提交的哈希字串，或是标签作为`<commit>`参数。这会使你处在分离HEAD的状态。
+
+### 讨论
+
+版本控制系统背后的思想就是『安全』地储存项目的拷贝，这样你永远不用担心什么时候不可复原地破坏了你的代码库。当你建立了项目历史之后，`git checkout`是一种便捷的方式，来将保存的快照『加载』到你的开发机器上去。
+
+检出之前的提交是一个只读操作。在查看旧版本的时候绝不会损坏你的仓库。你项目『当前』的状态在	`master`上不会变化。在开发的正常阶段，`HEAD`一般指向master或是其他的本地分支，但当你检出之前提交的时候，`HEAD`就不再指向一个分支了——它直接指向一个提交。这被称为『分离`HEAD`』状态 ，可以用下图可视化：
+
+
+
+![Git Tutorial: Checking out a previous commit](https://www.atlassian.com/git/images/tutorials/getting-started/viewing-old-commits/01.svg)
+
+
+
+在另一方面，检出旧文件不影响你仓库的当前状态。你可以在新的快照中像其他文件一样重新提交旧版本。所以，在效果上，`git checkout`的这个用法可以用来将单个文件回滚到旧版本 。
+
+
+
+![Git Training: Checking out a previous version of a file](https://www.atlassian.com/git/images/tutorials/getting-started/viewing-old-commits/02.svg)
+
+
+
+### 栗子
+
+#### 查看之前的版本
+
+这个栗子假定你开始了一个疯狂的实验，但你不确定你是否想要保留它。为了帮助你决定，你想看一看你开始实验之前的项目状态。首先，你需要找到你想要看的那个版本的ID。
+
+``` 
+git log --oneline
+```
+
+假设你的项目历史看上去和下面一样：
+
+``` 
+b7119f2 继续做些丧心病狂的事
+872fa7e 做些丧心病狂的事
+a1e8fb5 对hello.py做了一些修改
+435b61d 创建hello.py
+9773e52 初始导入
+```
+
+你可以这样使用`git checkout`来查看『对hello.py做了一些修改』这个提交：
+
+``` 
+git checkout a1e8fb5
+```
+
+这让你的工作目录和`a1e8fb5`提交所处的状态完全一致。你可以查看文件，编译项目，运行测试，甚至编辑文件而不需要考虑是否会影响项目的当前状态。你所做的一切 *都不会* 被保存到仓库中。为了继续开发，你需要回到你项目的『当前』状态：
+
+``` 
+git checkout master
+```
+
+这里假定了你默认在master分支上开发，我们会在以后的分支模型中详细讨论。
+
+一旦你回到master分支之后，你可以使用 `git revert`或`git reset`来回滚任何不想要的更改。
+
+#### 检出文件
+
+如果你只对某个文件感兴趣，你也可以用`git checkout`来获取它的一个旧版本。比如说，如果你只想从之前的提交中查看`hello.py`文件，你可以使用下面的命令：
+
+``` 
+git checkout a1e8fb5 hello.py
+```
+
+记住，和检出提交不同，这里 *确实* 会影响你项目的当前状态。旧的文件版本会显示为『需要提交的更改』，允许你回滚到文件之前的版本。如果你不想保留旧的版本，你可以用下面的命令检出到最近的版本：
+
+``` 
+git checkout HEAD hello.py
+```

wiki/catagory.md

@@ -8,7 +8,8 @@
 - **第2章** [创建代码仓库](https://github.com/geeeeeeeeek/git-recipes/wiki/2.2-%E5%88%9B%E5%BB%BA%E4%BB%A3%E7%A0%81%E4%BB%93%E5%BA%93)
 - **第3章** [保存你的更改](https://github.com/geeeeeeeeek/git-recipes/wiki/2.3-%E4%BF%9D%E5%AD%98%E4%BD%A0%E7%9A%84%E6%9B%B4%E6%94%B9)
 - **第4章** [查看仓库状态](https://github.com/geeeeeeeeek/git-recipes/wiki/2.4-%E6%A3%80%E6%9F%A5%E4%BB%93%E5%BA%93%E7%8A%B6%E6%80%81)
-- **第5章** 查看以前的提交  **第6章** 回滚错误的更改  **第7章** 重写项目历史
+- **第5章** [检出之前的提交](https://github.com/geeeeeeeeek/git-recipes/wiki/2.5-%E6%A3%80%E5%87%BA%E4%B9%8B%E5%89%8D%E7%9A%84%E6%8F%90%E4%BA%A4) 
+- **第6章** 回滚错误的更改  **第7章** 重写项目历史
 
 **第3章 远程团队协作和管理**
 
@@ -17,37 +18,37 @@
 **第4篇 Git命令详解**
 
 - **第1章** [图解Git命令](https://github.com/geeeeeeeeek/git-recipes/wiki/4.1-%E5%9B%BE%E8%A7%A3Git%E5%91%BD%E4%BB%A4)
-
+  
   如果你稍微理解git的工作原理，这篇文章能够让你理解的更透彻。
 
 **第5篇 Git实用贴士**
 
 - **第1章** [代码合并：Merge、Rebase的选择](https://github.com/geeeeeeeeek/git-recipes/wiki/5.1-%E4%BB%A3%E7%A0%81%E5%90%88%E5%B9%B6%EF%BC%9AMerge%E3%80%81Rebase%E7%9A%84%E9%80%89%E6%8B%A9)
-
+  
   `git rebase` 和`git merge` 都是用来合并分支，只不过方式不太相同。`git rebase` 经常被人认为是一种Git巫术，初学者应该避而远之。但如果使用得当，它能省去太多烦恼。在这篇文章中，我们会通过比较找到Git工作流中所有可以使用rebase的机会。
-
+  
 - **第2章** [代码回滚：Reset、Checkout、Revert的选择](https://github.com/geeeeeeeeek/git-recipes/wiki/5.2-%E4%BB%A3%E7%A0%81%E5%9B%9E%E6%BB%9A%EF%BC%9AReset%E3%80%81Checkout%E3%80%81Revert%E7%9A%84%E9%80%89%E6%8B%A9)
-
+  
   git reset、git checkout和git revert都是用来撤销代码仓库中的某些更改，所以我们经常弄混。在这篇文章中，我们比较最常见的用法，分析在什么场景下该用哪个命令。
-
+  
 - **第3章** [Git log高级用法](https://github.com/geeeeeeeeek/git-recipes/wiki/5.3-Git-log%E9%AB%98%E7%BA%A7%E7%94%A8%E6%B3%95)
-
+  
   任何一个版本控制系统设计的目的都是为了记录你代码的变化——谁贡献了什么，找出bug是什么时候引入的，以及撤回一些有问题的更改。`git log` 可以格式化commit输出的形式，或过滤输出的commit从而找到项目中你需要的任何信息。
-
+  
 - **第4章** [Git钩子：自定义你的工作流](https://github.com/geeeeeeeeek/git-recipes/wiki/5.4-Git%E9%92%A9%E5%AD%90%EF%BC%9A%E8%87%AA%E5%AE%9A%E4%B9%89%E4%BD%A0%E7%9A%84%E5%B7%A5%E4%BD%9C%E6%B5%81)
-
+  
   Git钩子是在Git仓库中特定事件发生时自动运行的脚本。它可以让你自定义Git内部的行为，在开始周期中的关键点触发自定义的行为，自动化或者优化你开发工作流中任意部分。
-
+  
 - **第5章** [Git提交引用和引用日志](https://github.com/geeeeeeeeek/git-recipes/wiki/5.5-Git%E6%8F%90%E4%BA%A4%E5%BC%95%E7%94%A8%E5%92%8C%E5%BC%95%E7%94%A8%E6%97%A5%E5%BF%97)
-
+  
   提交是Git的精髓所在，你无时不刻不在创建和缓存提交、查看以前的提交，或者用各种Git命令在仓库间转移你的提交。在这章中，我们研究提交的各种引用方式，以及涉及到的Git命令的工作原理。我们还会学到如何使用Git的引用日志查看看似已经删除的提交。
 
 **第6篇 Git应用实践：用GitLab搭建一个课程教学仓库**
 
 - **第1章** 教师和学生的最佳实践指南
-
+  
   GitLab本身的权限管理和组织结构已经满足了教学中课程创建、学生管理、收发作业、通知统计等需求。不过，在实践中我们要尤其注意各处的权限和命名规范。因此，我总结了一份教师和学生的最佳实践指南，保证各门课程能够顺畅地进行。
-
+  
 - **第2章** 在上层搭建一个Classroom应用
-
+  
   在实践中，我们要手动地导入大量学生、创建分支以及在Gitlab复杂的页面中穿梭。显然我们可以做得更好，那就是在GitLab上再搭建一层Classroom应用。在这章中，我会介绍我们是如何抽取需求，以及构建这个应用的。