Add 2.4 检查仓库状态.

sources/查看仓库状态.md

@@ -0,0 +1,173 @@
+# 检查仓库状态
+
+> BY 童仲毅(geeeeeeeeek@github)
+> 
+> 这是一篇在[原文](https://www.atlassian.com/git/tutorials/inspecting-a-repository/git-log)基础上演绎的译文。除非另行注明，页面上所有内容采用知识共享-署名([CC BY 2.5 AU](http://creativecommons.org/licenses/by/2.5/au/deed.zh))协议共享。
+
+## git status
+
+`git status`命令显示工作目录和缓存区的状态。你可以看到哪些更改被缓存了，哪些还没有，以及哪些还未被Git追踪。status的输出 *不会* 告诉你任何已提交到项目历史的信息。如果你想看的话，应该使用`git log`命令。
+
+### 用法
+
+``` 
+git status
+```
+
+列出已缓存、未缓存、未追踪的文件。
+
+### 讨论
+
+`git status`是一个相对简单的命令。 它告诉你`git add`和`git commit`的进展。status信息还包括了添加缓存和移除缓存的相关指令。样例输出显示了三类主要的`git status`输出：
+
+``` 
+# On branch master
+# Changes to be committed:
+# (use "git reset HEAD <file>..." to unstage)
+#
+#modified: hello.py
+#
+# Changes not staged for commit:
+# (use "git add <file>..." to update what will be committed)
+# (use "git checkout -- <file>..." to discard changes in working directory)
+#
+#modified: main.py
+#
+# Untracked files:
+# (use "git add <file>..." to include in what will be committed)
+#
+#hello.pyc
+```
+
+#### 忽略文件
+
+未追踪的文件通常有两类。它们要么是项目新增但还未提交的文件，要么是像`.pyc` `.obj`  `.exe`等编译后的二进制文件。显然前者应该出现在`git status`的输出中，而后者会让我们困惑究竟发生了什么。
+
+因此，Git允许你完全忽略这些文件，只需要将路径放在一个特定的`.gitignore`文件中。所有想要忽略的文件应该分别写在单独一行，*字符用作通配符。比如，将下面这行加入项目根目录的`.gitignore`文件可以避免编译后的Python模块出现在`git status`中：
+
+``` 
+*.pyc
+```
+
+### 栗子
+
+在提交更改前检查仓库状态是一个良好的实践，这样你就不会不小心提交什么奇怪的东西。这个例子显示了缓存和提交快照前后的仓库状态：
+
+``` 
+# Edit hello.py
+git status
+# hello.py is listed under "Changes not staged for commit"
+git add hello.py
+git status
+# hello.py is listed under "Changes to be committed"
+git commit
+git status
+# nothing to commit (working directory clean)
+```
+
+第一个status的输出显示文件还未缓存。`git add`操作会影响第二个`git status`，最后的status输出告诉你已经没有可以提交的东西了——工作目录和最近的提交一致。一些Git命令（比如`git merge`）需要工作目录整洁，以免意外覆盖更改。
+
+## git log
+
+`git log` 命令显示已提交的快照。你可以列出项目历史，筛选，以及搜索特定更改。`git status` 允许你查看工作目录和缓存区，而`git log`只作用于提交的项目历时。
+
+
+
+![Git Tutorial: git status vs. git log](https://www.atlassian.com/git/images/tutorials/getting-started/inspecting-a-repository/01.svg)
+
+log输出可以有很多种自定义的方式，从简单地筛选提交，到用完全自定义的格式显示。其中一些最常用的`git log`配置如下所示。
+
+### 用法
+
+``` 
+git log
+```
+
+使用默认格式显示完整地项目历史。如果输出超过一屏，你可以用`空格键`来滚动，按`q`退出。
+
+``` 
+git log -n <limit>
+```
+
+用`<limit>`限制提交的数量。比如`git log -n 3`只会显示3个提交。
+
+``` 
+git log --oneline
+```
+
+将每个提交压缩到一行。当你需要查看项目历史的上层情况时这会很有用。
+
+``` 
+git log --stat
+```
+
+除了`git log`信息之外，包含哪些文件被更改了，以及每个文件相对的增删行数。
+
+``` 
+git log -p
+```
+
+显示代表每个提交的一堆信息。显示每个提交全部的差异(diff)，这也是项目历史中最详细的视图。
+
+``` 
+git log --author="<pattern>"
+```
+
+搜索特定作者的提交。`<pattern>`可以是字符串或正则表达式。
+
+``` 
+git log --grep="<pattern>"
+```
+
+搜索提交信息匹配特定`<pattern>`的提交。`<pattern>`可以是字符串或正则表达式。
+
+``` 
+git log <since>..<until>
+```
+
+只显示发生在`<since>`和`<until>`之间的提交。两个参数可以是提交ID、分支名、`HEAD`或是任何一种引用。
+
+``` 
+git log <file>
+```
+
+只显示包含特定文件的提交。查找特定文件的历史这样做会很方便。
+
+``` 
+git log --graph --decorate --oneline
+```
+
+还有一些有用的选项。`--graph`标记会绘制一幅字符组成的图形，左边是提交，右边是提交信息。`--decorate`标记会加上提交所在的分支名称和标签。`--oneline`标记将提交信息显示在同一行，一目了然。
+
+### 讨论
+
+`git log`命令是Git查看项目历史的基本工具。当你要寻找项目特定的一个版本或者弄明白合并功能分支时引入了哪些变化，你就会用到这个命令。
+
+``` 
+commit 3157ee3718e180a9476bf2e5cab8e3f1e78a73b7
+Author: John Smith
+```
+
+大多数时候都很简单直接。但是，第一行需要解释下。`commit`后面40个字的字符串是提交内容的SHA-1校验总和(checksum)。它有两个作用。一是保证提交的正确性——如果它被损坏了，提交会生成一个不同的校验总和。第二，它是提交唯一的标识ID。
+
+这个ID可以用于`git log ..`这样的命令中来引用具体的提交。比如，`git log 3157e..5ab91`会显示所有ID在 `3157e`和`5ab91`之间的提交。除了校验总和之外，分支名、HEAD关键字也是常用的引用提交的方法。`HEAD`总是指向当前的提交，无论是分支还是特定提交也好。
+
+~字符用于表示提交的父节点的相对引用。比如，`3157e~1`指向`3157e`前一个提交,`HEAD~3`是当前提交的回溯3个节点的提交。
+
+所有这些标识方法的背后都是为了让你对特定提交进行操作。`git log`命令一般是这些交互的起点，因为它让你找到你想要的提交。
+
+### 栗子
+
+*用法* 一节提供了`git log`很多的栗子，但请记住，你可以将很多选项用在同一个命令中：
+
+``` 
+git log --author="John Smith" -p hello.py
+```
+
+这个命令会显示`John Smith`作者对`hello.py`文件所做的所有更改的差异比较(diff)。
+
+..句法是比较分支很有用的工具。下面的栗子显示了在`some-feature`分支而不在`master`分支的所有提交的概览。
+
+``` 
+git log --oneline master..some-feature
+```