Merge pull request #56 from geeeeeeeeek/revision-2018

Revision 2018
2018-06-06 21:04:43 -07:00
parent 9fdddd9698 fcafcf3f86
commit 7290743fdd
5 changed files with 100 additions and 120 deletions
--- a/README.md
+++ b/README.md
@ -1,19 +1,74 @@
-# git-recipes
+# 🥡Git 菜单

-高质量的 Git 中文教程，来自国外社区的优秀文章和个人实践
+ *高质量的 Git 中文教程，源于国外社区的优秀文章和个人实践*

-## [目录](https://github.com/geeeeeeeeek/git-recipes/wiki/)
+🥢🥢🥢🥢🥢🥢

-git-recipes 的所有文章都以 Wiki 的方式呈现，请移步项目 [Wiki](https://github.com/geeeeeeeeek/git-recipes/wiki/) 查看目录和详细内容。
+### 第1篇 果壳中的 Git

-## 我为什么要做这份菜单
+- **第1章** [什么是 Git](https://github.com/geeeeeeeeek/git-recipes/wiki/1.1-%E6%9E%9C%E5%A3%B3%E4%B8%AD%E7%9A%84-Git)

-在整理 Git 资料的时候，我发现社区贡献了非常多高质量的博客文章、指南等等。尤其英文的那些资料，除了大家熟知的「Git 图解」，还有好多优秀的文章仍无人翻译。此外，这些资料往往只涉及某些特定的话题，如果能有一份菜单将这些菜谱以特定的方式串起来，那么对于 Git 学习者来说将会是极大的便利。尤其对于我这样热爱查阅社区资料胜过出版物的懒人 :] 随着我的学习节奏还会不断有新的菜谱加入进来，或许不会很频繁，不过也没有确定的终点。
+### 第2篇 从零搭建本地代码仓库

-## 版权说明
+本篇完全面向入门者。我假设你从零开始创建一个项目并且想用 Git 来进行版本控制，我们会讨论如何在你的个人项目中使用 Git，比如如何初始化你的项目，如何管理新的或者已有的文件，如何在远端仓库中储存你的代码。

-除非另行注明，这个项目中的所有内容采用知识共享-署名（[CC BY 2.5 AU](http://creativecommons.org/licenses/by/2.5/au/deed.zh)）协议共享，BY 童仲毅（geeeeeeeeek@github）。
+- **第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章** [检查仓库状态](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章** [检出之前的提交](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章** [回滚错误的修改](https://github.com/geeeeeeeeek/git-recipes/wiki/2.6-%E5%9B%9E%E6%BB%9A%E9%94%99%E8%AF%AF%E7%9A%84%E4%BF%AE%E6%94%B9)
+- **第7章** [重写项目历史](https://github.com/geeeeeeeeek/git-recipes/wiki/2.7-%E9%87%8D%E5%86%99%E9%A1%B9%E7%9B%AE%E5%8E%86%E5%8F%B2)

-不少文章在原基础上翻译或演绎而来，页面上方均标明了原作者、原文链接以及原文采用的协议。如仍有版权疑问，请在 Issue 中提出。
+### 第3篇 远程团队协作和管理

-欢迎通过 Issue 或者 Pull Request 推荐你认为合适的资料，让这份菜单更充实一些。
+- **第1章** 快速指南
+- **第2章** [保持同步](https://github.com/geeeeeeeeek/git-recipes/wiki/3.2-%E4%BF%9D%E6%8C%81%E5%90%8C%E6%AD%A5)
+- **第3章** [创建 Pull Request](https://github.com/geeeeeeeeek/git-recipes/wiki/3.3-%E5%88%9B%E5%BB%BA-Pull-Request)
+- **第4章** [使用分支](https://github.com/geeeeeeeeek/git-recipes/wiki/3.4-%E4%BD%BF%E7%94%A8%E5%88%86%E6%94%AF)
+- **第5章** [常见工作流比较](https://github.com/geeeeeeeeek/git-recipes/wiki/3.5-%E5%B8%B8%E8%A7%81%E5%B7%A5%E4%BD%9C%E6%B5%81%E6%AF%94%E8%BE%83)
+
+### 第4篇 Git 命令详解
+
+- **第1章** [图解 Git 命令](https://github.com/geeeeeeeeek/git-recipes/wiki/4.1-%E5%9B%BE%E8%A7%A3-Git-%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 的引用日志查看看似已经删除的提交。
+
+🥢🥢🥢🥢🥢🥢
+
+### 版权说明
+
+- ✍️ [童仲毅 (geeeeeeeeek@github)](https://github.com/geeeeeeeeek)
+- 除非另行注明，这个项目中的所有内容采用知识共享-署名（[CC BY 2.5 AU](http://creativecommons.org/licenses/by/2.5/au/deed.zh)）协议共享。
+- 不少文章在原基础上翻译或演绎而来，页面上方标注了原作者、原文链接以及原文采用的协议。如有版权疑问，请在 Issue 中提出。
+- 欢迎通过 Issue 或者 Pull Request 推荐你认为合适的资料，让这份菜单更充实一些。
+
+🥢🥢🥢🥢🥢🥢
+
+### 为什么要做这份菜单
+
+> 在整理 Git 资料的时候，我发现社区贡献了非常多高质量的博客文章、指南等等。尤其英文的那些资料，除了大家熟知的「Git 图解」，还有好多优秀的文章仍无人翻译。此外，这些资料往往只涉及某些特定的话题，如果能有一份菜单将这些菜谱以特定的方式串起来，那么对于 Git 学习者来说将会是极大的便利。尤其对于我这样热爱查阅社区资料胜过出版物的懒人 :] 随着我的学习节奏还会不断有新的菜谱加入进来，或许不会很频繁，不过也没有确定的终点。
+>
+> 📅 *写于 2015 年*
--- a/sources/果壳中的Git.md
+++ b/sources/果壳中的Git.md
@ -1,77 +1,76 @@
-# 什么是Git
+# 什么是 Git

-> BY houkensjtu（[houkensjtu@github](https://github.com/houkensjtu)）
+> ✍️ [houkensjtu](https://github.com/houkensjtu) | [童仲毅](https://github.com/geeeeeeeeek)
 >
-> 这是一篇在[原文（BY atlassian）](https://www.atlassian.com/git/tutorials/what-is-git)基础上演绎的译文。除非另行注明，页面上所有内容采用知识共享-署名（[CC BY 2.5 AU](http://creativecommons.org/licenses/by/2.5/au/deed.zh)）协议共享。
+> ©️ 本文演绎自 Atlassian 编写的 [_What is Git_](https://www.atlassian.com/git/tutorials/what-is-git)。页面上所有内容采用知识共享-署名（[CC BY 2.5 AU](http://creativecommons.org/licenses/by/2.5/au/deed.zh)）许可协议。

-Git 是目前世界上被最广泛使用的现代软件版本管理系统。Git 本身亦是一个成熟并处于活跃开发状态的开源项目，它最初是由 Linux 操作系统内核的创造者 Linus Torvalds 在 2005 年创造。今天惊人数量的软件项目依赖 Git 进行版本管理，这些项目包括开源以及各种商业软件。Git 在职业软件开发者中拥有良好的声誉，Git 目前支持绝大多数的操作系统以及 IDE（Integrated Development Environments）。
+到目前为止，Git 是世界上使用最为广泛的现代化版本控制系统。Git 最初由 Linux 系统内核的作者 Linus Torvalds 在 2005 年开始开发，目前已经是一个持续维护的成熟开源项目。如今，大量软件项目依赖 Git 进行版本管理，其中既有开源软件，也有商业软件。Git 在很多操作系统和集成开发环境（IDE）上都表现良好。绝大多数软件开发者或多或少都使用过 Git。

-Git 使用分散式架构，是分散式版本管理 DVCS（Distributed Version Control System）的代表。相较于例如 CVS 或者 Subversion 等集中式版本管理软件，Git 并不是将代码的所有修改历史保存在中心服务器中。在 Git 中取而代之的是，所有参与项目的开发者都拥有各自的代码完全拷贝，并在自己的拷贝上进行软件开发。
+Git 是分布式版本管理（DVCS）的一种。CVS 和 Subversion（SVN） 等集中式的版本管理软件将完整的版本历史存放在同一个地方。而在 Git 中，每个开发者的代码仓库都包含了所有变更历史。

-除了分散式的特点之外，Git 的设计也针对性能，安全性和柔软性作了特别优化。
+除了分布式之外，Git 在设计之初也考虑了性能、安全性和灵活性。

-### 性能
+### 高性能

-Git 的底层性能相较于其他版本管理软件有强大的优势。在 Git 中所有的操作包括提交修改，创建分支，融合分支，以及求取差分都经过了性能优化。这些优化来自于 Git 的开发者对实际一般代码开发模式的深度认识和广泛知识。
+Git 的底层性能相较于其他版本管理软件有强大的优势。提交修改、创建分支、合并分支和比较版本都针对性能进行了优化。Git 中实现的算法利用了现实中代码树的特点以及它们被修改和访问的常见模式。

-不同于某些版本管理软件，Git 在决定代码修改历史以及保存形式的时候不会被文件名的变化所愚弄，Git 关注的是文件的内容本身。在实际操作中，代码文件经历频繁的再命名，分解和合并。Git 使用一种混合了差分编码（delta encoding，仅保存代码修改的差分），压缩，直接保存，以及版本元数据（version metadata objects）的管理方式。
+不同于某些版本管理软件，Git 在决定文件树的储存和版本历史时，不会被文件名的变化所愚弄——Git 关注的是文件的内容本身。毕竟，代码文件经常会被重命名、拆分和重新编排。Git 仓库中的文件对象通过差分编码（delta encoding，仅保存代码修改的差分）和压缩技术储存，并且直接保存文件夹中的内容和版本控制元数据。

-分散式的架构也给 Git 带来了极大的性能优势。
+分布式架构也给 Git 带来了巨大的性能优势。

-比如说，现有一名开发成员 Alice 对代码进行了一些改动，添加了一些在2.0版本中准备公开的功能，然后将这些修改以及一份简单的说明进行了提交。随后她又增加了一些另外的新功能，并又作了一次新提交。显然这两次修改在版本历史中被分开各自进行了保存。在这之后 Alice 把代码切换到了 1.3 版本，修复了一些旧版本中的 Bug（这和她新添加的功能没有关系）。这次修复的目的是为了让团队可以在公开 2.0 版本之前，释放一个 1.3.1 版本来解决 1.3 版本中的 Bug 问题。Alice 马上又可以回到她之前进行的 2.0 版本功能开发之中（通过切换代码分支），这些操作由于 Git 的分散属性，都不需要通过网络来连接到中央服务器进行，她甚至可以在飞机中完成这一切。当她完成所有工作，只需要向远程的代码库推送（Push）自己的修改即可。
+比如说，有一名开发成员 Alice 修改了代码，添加了一些准备在 2.0 版本中发布的功能，然后提交了这些修改及其描述。随后，她又编写并提交了另一个新功能。很自然地，这两次修改是版本历史中两份独立的工作。Alice 又切换到了 1.3 版本的分支，修复了一个只影响这个旧版本的 bug。这次修复的目的是为了让团队在 2.0 版本还没有完成之前，发布一个 1.3.1 版本来解决旧版本中的一些 bug。Alice 可以立刻回到 2.0 版本分支，继续新功能开发。这一切都不需要网络连接，非常快速可靠，甚至可以在飞机中完成。当她准备好将这些单独提交的更改发送到远程仓库时，她只需要一个“推送”（push）命令。

-### 安全性
+### 安全

-Git 将保持所管理代码的整合性作为首要要务。所有的文件内容，文件相互关系，以及文件目录结构，版本，标签以及修改，都经过加密哈希校验算法（SHA1）的保护。这可以防止各种意外的代码修改失误，或者是第三者的恶意修改，使得代码修改历史完全可追迹。
+Git 设计时就把托管代码的完好性作为重中之重。文件内容以及文件、目录、版本、标签和提交的关联，都通过安全的加密哈希校验算法（SHA1）保护。这可以避免代码和修改历史被不小心或者恶意改变，并且保证修改历史完全可追迹。

-使用 Git 你可以确信你拥有代码的完整修改历史。
+你可以相信在 Git 中源代码的修改历史是真实可靠的。

-某些其他的版本管理软件对发布后的代码不进行任何保护。这对于完全依赖于软件开发的团队来说可以是一种非常严重的安全脆弱性问题。
+有一些版本管理软件无法防止版本历史之后被篡改。这对于任何依赖软件开发的团队来说都是严重的安全漏洞。

-### 柔软性
+### 灵活

-Git 的关键设计目标之一就是保持柔软性。Git 在以下方面都展现出了其柔软性：支持各种非线性的开发工作流程，对或大或小的软件项目都可以良好支持，以及兼容各种操作系统和协议。
+Git 的关键设计目标之一就是灵活。Git 在很多方面都展现出了其灵活性：支持多种非线性的工作流，对不同规模的项目来说都很高效，并且兼容多个操作系统和协议。

-Git 支持将分支和标签作为一级基本对象（不同于 SVN），所以所有对分支和标签的操作也都会被保存到修改历史中。并不是所有的版本管理软件支持这一层面的追迹。
+Git 在设计时最重要的功能便是分支和标签（不同于 SVN），因此所有影响分支和标签的操作也都会被保存到修改历史中。不是所有的版本管理软件关注的都是这个层面的版本追踪。

 ### 使用 Git 进行版本管理

-Git 对今天绝大多数软件开发团队来说都是最佳的选择。虽然每个团队都有各自的特点和目标，但是这里我们依然可以列举一些对他们来说Git优于其他选择的理由：
+Git 对于绝大多数软件开发团队来说都是最好的选择。虽然每个团队都需要考虑自身的情况，但我们依然可以列举一些 Git 比其他版本控制系统更好的理由：

-#### Git 很棒
+#### Git 很好用

-Git 兼备了功能性，高性能，安全性和柔软性，这些是很多软件开发团队以及个人所需要的要素。我们已经在上面详细讨论了这些特性。对很多软件开发团队来说，以以上标准货比三家的最终结果都是选择Git。
+Git 兼具大多数团队和个人开发者需要的功能、性能，安全性和灵活性。我们已经具体讨论过了这些特点。对很多团队来说，它们发现 Git 在这几点上都表现的更优秀。

-#### Git 已经成为了默认的行业标准
+#### Git 已经成为了事实上的行业标准

-Git 是受到最广泛使用和支持的版本管理软件。这使得 Git 在以下这些方面具有极大的吸引力。我们在 Atlassian（此 Tutorial 作者所处的公司）的大多数代码都是用 Git 来进行管理的。
+Git 使用最广泛的版本管理软件。这使得 Git 在以下这些方面具有极大的吸引力。在 Atlassian（作者所在的公司），大多数代码都是通过 Git 管理的。

-绝大多数的软件开发者都有过 Git 的使用经历，很大一部分在校或者刚刚毕业的学生甚至只用过 Git 进行版本管理。虽然在一些公司开发成员可能在从其他版本管理软件迁移到 Git 的过程中要经历比较陡峭的学习曲线，但是大多数开发者以及他们未来的潜在开发者（学生）都已经具备了使用 Git 的基本技能，这就意味着他们不再需要额外的培训。
+大量开发者都有过 Git 的使用经历，很大一部分大学毕业生甚至只用过 Git 进行版本管理。虽然迁移到 Git 的过程中或许会经历比较陡峭的学习曲线，但是大多数员工以及未来的员工都已经具备了使用 Git 的基本技能，这意味着他们不需要额外的培训。

-Git 的普及还带来很多其他的好处，Git 的市场占有率意味着很多第三方的服务和 IDE 都开始默认支持 Git。比如我们的 DVCS 客户端 [Source
-Tree](https://www.atlassian.com/software/sourcetree)，项目开发管理软件 [JIRA](https://www.atlassian.com/software/jira)，以及代码托管服务 [Bitbucket](https://www.atlassian.com/software/bitbucket)。
+除了拥有大量使用者之外，Git 的普及还意味着很多第三方的服务和 IDE 都已经集成了 Git。比如我们的 DVCS 桌面客户端 [Source Tree](https://www.atlassian.com/software/sourcetree)、项目开发管理软件 [JIRA](https://www.atlassian.com/software/jira) 和代码托管服务 [Bitbucket](https://www.atlassian.com/software/bitbucket)。

-如果你是一个开发新手并期待在未来构建自己的专业开发技能，Git 毫无疑问是你在版本管理上的第一选择。
+如果你是一个想要积累软件开发工具使用技能的新人，Git 毫无疑问是你在版本管理方面的第一选择。

 #### Git 是一个高质量的开源项目

-Git 本身是一个拥有良好支持和管理的开源软件项目。Git 的开发者在过去的十年中展现了良好的公平性，成熟的开发手段以保障其用户将来的需求，以及定期的更新以保持其可用性和功能性。开源的特性使得项目代码本身受到无微不至的检查，现在有无数的企业都依赖于 Git 的超高软件开发质量。
+Git 本身是一个经历多年良好支持和管理的开源软件项目。Git 的维护者很好地平衡了长远的用户需求，和改进可用性和功能性的例行更新。这个开源项目的质量久经考验，无数企业都极度依赖于此。

-Git 同时享有极好的社区支持和庞大的用户群体。你可以找到各种内容深入浅出的学习资料，包括书籍，教程，以及专题网站。甚至还有广播以及视频教程存在。
+Git 还拥有良好的社区支持和庞大的用户群体。你可以找到各种深入浅出的学习资料，包括书籍，教程，以及专题网站。你也可以找到相关的播客节目和视频教程。

-保持开源降低了编程爱好者的投入成本因为他们不需要花一分钱来使用 Git。在开源项目中，Git 无疑扮演了前一世代版本管理软件，比如 SVN 和 CVS，的成功接班人。
+开源降低了业余开发者的成本，因为他们不需要花一分钱来使用 Git。对于开源项目来说，Git 无疑是 SVN 和 CVS 等上一代流行版本管理软件的接班人。

-#### 对于 Git 的批评意见
+#### 对 Git 的批评

-对于 Git 的一个常见批评是它非常难以掌握。Git 中的某些术语对刚上手的朋友或者是使用其他系统的朋友可能会比较陌生，比如说，`revert` 这个命令在 Git 中和在 SVN 或者 CVS 中具有不同的含义。不过尽管如此，Git 依然向用户提供了非常强大的功能。学习掌握这些功能也许会花一些时间，但是一旦你学会了这些技能，它们会帮助你大大提高团队的开发效率。
+对于 Git 的一个常见批评是它学起来不那么容易。Git 中的某些术语对于新手或者是使用其他系统的朋友可能会比较陌生。比如说，`revert` 这个命令在 Git、SVN、CVS 中具有不同的含义。不过，Git 向用户提供了非常强大的功能。学习掌握这些功能也许会花一些时间，但是一旦你学会了这些技能，它们会帮助你大大提高团队的开发效率。

-对于曾经使用非分散式版本管理的团队来说，保存代码的中央服务器可能是他们所不想舍去的。不过，虽然 Git 的确是分散式的架构设计，但是你依然可以设立一个「官方」的代码库来强制保存所有的修改。使用 Git 时，由于所有的开发者都拥有完整的代码库拷贝，所以他们的工作不会被中央服务器的性能甚至有无左右。即便他们下线或者在外，他们依然可以随时查看代码库的修改历史。得益于 Git 的分散式特性，你可以保持自己原有的工作方式但得到 Git 带来的额外好处，有时候你甚至会发现自己不曾意识到有些事居然还可以这样干。
+对于曾经使用非分布式版本管理的团队来说，他们可能不想放弃中央服务器。不过，虽然 Git 被设计成分布式的架构，你依然可以建立一个“官方”的代码库来存放所有的修改。使用 Git 时，由于所有的开发者都拥有完整的代码库拷贝，所以他们的工作不会被中央服务器的状态和性能所影响。即使遇到故障，他们依然可以查看完整的项目历史。得益于 Git 的灵活性和分布式特点，你可以在保持原有工作方式的同时还可以得到 Git 带来的额外好处，而你以前甚至不会意识到这些好处。

-现在你明白了什么是版本管理，什么是 Git 以及为什么我们要选择使用 Git ，接下来你可以选择阅读下一篇文章，在那里我们将解释 Git 给团队和业务所带来的好处。
+现在你已经明白了什么是版本管理，什么是 Git 以及为什么要使用 Git ，你可以选择继续阅读下一节，了解 Git 在整个组织层面带来的好处。


-> 这篇文章是[**「git-recipes」**](https://github.com/geeeeeeeeek/git-recipes/)的一部分，点击 [**目录**](https://github.com/geeeeeeeeek/git-recipes/wiki/) 查看所有章节。
+> 这篇文章是[**「Git Recipes」**](https://github.com/geeeeeeeeek/git-recipes/)的一部分，点击 [**目录**](https://github.com/geeeeeeeeek/git-recipes/wiki/) 查看所有章节。
 >
 > 如果你觉得文章对你有帮助，欢迎点击右上角的 **Star** :star2: 或 **Fork** :fork_and_knife:。
 >
-> 如果你发现了错误，或是想要加入协作，请参阅 [Wiki 协作说明](https://github.com/geeeeeeeeek/git-recipes/issues/1)。
+> 如果你发现了错误，或是想要加入协作，请参阅 [协作说明](https://github.com/geeeeeeeeek/git-recipes/issues/1)。
--- a/wiki/about.md
+++ b/wiki/about.md
@ -1,19 +0,0 @@
-git-recipes
-====
-高质量的 Git 中文教程，来自国外社区的优秀文章和个人实践
-
-目录
---
-git-recipes 的所有文章都以 Wiki 的方式呈现，请移步[项目Wiki](https://github.com/geeeeeeeeek/git-recipes/wiki/)查看目录和详细内容。
-
-我为什么要做这份菜单
---
-在整理 Git 资料的时候，我发现社区贡献了非常多高质量的博客文章、指南等等。尤其英文的那些资料，除了大家熟知的《Git 图解》，还有好多优秀的文章仍无人翻译。此外，这些资料往往只涉及某些特定的话题，如果能有一份菜单将这些菜谱以特定的方式串起来，那么对于 Git 学习者来说将会是极大的便利。尤其对于我这样热爱查阅社区资料胜过出版物的懒人 :] 随着我的学习节奏还会不断有新的菜谱加入进来，或许不会很频繁，不过也没有确定的终点。
-
-版权说明
---
-除非另行注明，这个项目中的所有内容采用知识共享-署名（[CC BY 2.5 AU](http://creativecommons.org/licenses/by/2.5/au/deed.zh)）协议共享，童仲毅（geeeeeeeeek@github）版权所有。
-
-其中不少资料是在原基础上翻译或演绎而来的，我都在页面最上方标明了原作者、原文链接以及原文采用的协议。如仍有版权疑问，请在 Issue 中提出。
-
-欢迎通过 Issue 或者 Pull Request 推荐你认为合适的资料，让这份菜单更充实一些。
--- a/wiki/catagory.md
+++ b/wiki/catagory.md
@ -1,50 +0,0 @@
-**第1篇 Git 是什么？**
-
- **第1章** [果壳中的 Git](https://github.com/geeeeeeeeek/git-recipes/wiki/1.1-%E6%9E%9C%E5%A3%B3%E4%B8%AD%E7%9A%84-Git)
-
-**第2篇 从零搭建本地代码仓库**
-
-本篇完全面向入门者。我假设你从零开始创建一个项目并且想用 Git 来进行版本控制，我们会讨论如何在你的个人项目中使用 Git，比如如何初始化你的项目，如何管理新的或者已有的文件，如何在远端仓库中储存你的代码。
-
- **第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章** [检查仓库状态](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章** [检出之前的提交](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章** [回滚错误的修改](https://github.com/geeeeeeeeek/git-recipes/wiki/2.6-%E5%9B%9E%E6%BB%9A%E9%94%99%E8%AF%AF%E7%9A%84%E4%BF%AE%E6%94%B9)
- **第7章** [重写项目历史](https://github.com/geeeeeeeeek/git-recipes/wiki/2.7-%E9%87%8D%E5%86%99%E9%A1%B9%E7%9B%AE%E5%8E%86%E5%8F%B2)
-
-**第3篇 远程团队协作和管理**
- **第1章** 快速指南
- **第2章** [保持同步](https://github.com/geeeeeeeeek/git-recipes/wiki/3.2-%E4%BF%9D%E6%8C%81%E5%90%8C%E6%AD%A5)
- **第3章** [创建 Pull Request](https://github.com/geeeeeeeeek/git-recipes/wiki/3.3-%E5%88%9B%E5%BB%BA-Pull-Request)
- **第4章** [使用分支](https://github.com/geeeeeeeeek/git-recipes/wiki/3.4-%E4%BD%BF%E7%94%A8%E5%88%86%E6%94%AF)
- **第5章** [常见工作流比较](https://github.com/geeeeeeeeek/git-recipes/wiki/3.5-%E5%B8%B8%E8%A7%81%E5%B7%A5%E4%BD%9C%E6%B5%81%E6%AF%94%E8%BE%83)
-
-**第4篇 Git 命令详解**
-
- **第1章** [图解 Git 命令](https://github.com/geeeeeeeeek/git-recipes/wiki/4.1-%E5%9B%BE%E8%A7%A3-Git-%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 的引用日志查看看似已经删除的提交。
--- a/wiki/footer.md
+++ b/wiki/footer.md
@ -1,5 +0,0 @@
-这篇文章是[**「git-recipes」**](https://github.com/geeeeeeeeek/git-recipes/)的一部分，点击 [**目录**](https://github.com/geeeeeeeeek/git-recipes/wiki/) 查看所有章节。
-
-如果你觉得文章对你有帮助，欢迎点击右上角的 **Star** :star2: 或 **Fork** :fork_and_knife:。
-
-如果你发现了错误，或是想要加入协作，请参阅 [Wiki 协作说明](https://github.com/geeeeeeeeek/git-recipes/issues/1)。