diff --git a/sources/查看仓库状态.md b/sources/查看仓库状态.md new file mode 100644 index 0000000..24f0799 --- /dev/null +++ b/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 ..." to unstage) +# +#modified: hello.py +# +# Changes not staged for commit: +# (use "git add ..." to update what will be committed) +# (use "git checkout -- ..." to discard changes in working directory) +# +#modified: main.py +# +# Untracked files: +# (use "git add ..." 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 +``` + +用``限制提交的数量。比如`git log -n 3`只会显示3个提交。 + +``` +git log --oneline +``` + +将每个提交压缩到一行。当你需要查看项目历史的上层情况时这会很有用。 + +``` +git log --stat +``` + +除了`git log`信息之外，包含哪些文件被更改了，以及每个文件相对的增删行数。 + +``` +git log -p +``` + +显示代表每个提交的一堆信息。显示每个提交全部的差异(diff)，这也是项目历史中最详细的视图。 + +``` +git log --author="" +``` + +搜索特定作者的提交。``可以是字符串或正则表达式。 + +``` +git log --grep="" +``` + +搜索提交信息匹配特定``的提交。``可以是字符串或正则表达式。 + +``` +git log .. +``` + +只显示发生在``和``之间的提交。两个参数可以是提交ID、分支名、`HEAD`或是任何一种引用。 + +``` +git log +``` + +只显示包含特定文件的提交。查找特定文件的历史这样做会很方便。 + +``` +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 +``` \ No newline at end of file diff --git a/wiki/catagory.md b/wiki/catagory.md index 6811bc3..eeaa6d8 100644 --- a/wiki/catagory.md +++ b/wiki/catagory.md @@ -7,7 +7,8 @@ - **第1章** [快速指南](https://github.com/geeeeeeeeek/git-recipes/wiki/2.1-%E5%BF%AB%E9%80%9F%E6%8C%87%E5%8D%97) - **第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章** 查看仓库状态 **第5章** 查看以前的提交 **第6章** 回滚错误的更改 **第7章** 重写项目历史 +- **第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章** 重写项目历史 **第3章 远程团队协作和管理** @@ -17,51 +18,52 @@ - **第1章** [图解Git命令](https://github.com/geeeeeeeeek/git-recipes/wiki/4.1-%E5%9B%BE%E8%A7%A3Git%E5%91%BD%E4%BB%A4) - - 如果你稍微理解git的工作原理，这篇文章能够让你理解的更透彻。 - +``` +如果你稍微理解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的机会。 - +``` +`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都是用来撤销代码仓库中的某些更改，所以我们经常弄混。在这篇文章中，我们比较最常见的用法，分析在什么场景下该用哪个命令。 - +``` +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从而找到项目中你需要的任何信息。 - +``` +任何一个版本控制系统设计的目的都是为了记录你代码的变化——谁贡献了什么，找出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内部的行为，在开始周期中的关键点触发自定义的行为，自动化或者优化你开发工作流中任意部分。 - +``` +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的引用日志查看看似已经删除的提交。 - +``` +提交是Git的精髓所在，你无时不刻不在创建和缓存提交、查看以前的提交，或者用各种Git命令在仓库间转移你的提交。在这章中，我们研究提交的各种引用方式，以及涉及到的Git命令的工作原理。我们还会学到如何使用Git的引用日志查看看似已经删除的提交。 +``` **第6篇 Git应用实践：用GitLab搭建一个课程教学仓库** - **第1章** 教师和学生的最佳实践指南 - - GitLab本身的权限管理和组织结构已经满足了教学中课程创建、学生管理、收发作业、通知统计等需求。不过，在实践中我们要尤其注意各处的权限和命名规范。因此，我总结了一份教师和学生的最佳实践指南，保证各门课程能够顺畅地进行。 - +``` +GitLab本身的权限管理和组织结构已经满足了教学中课程创建、学生管理、收发作业、通知统计等需求。不过，在实践中我们要尤其注意各处的权限和命名规范。因此，我总结了一份教师和学生的最佳实践指南，保证各门课程能够顺畅地进行。 +``` - **第2章** 在上层搭建一个Classroom应用 - - 在实践中，我们要手动地导入大量学生、创建分支以及在Gitlab复杂的页面中穿梭。显然我们可以做得更好，那就是在GitLab上再搭建一层Classroom应用。在这章中，我会介绍我们是如何抽取需求，以及构建这个应用的。 +``` +在实践中，我们要手动地导入大量学生、创建分支以及在Gitlab复杂的页面中穿梭。显然我们可以做得更好，那就是在GitLab上再搭建一层Classroom应用。在这章中，我会介绍我们是如何抽取需求，以及构建这个应用的。 +``` \ No newline at end of file