今天是可乐喔！！！汽水！！

前言

因为前一阵子的面试，面试官都提到可以往 Github 上优秀的项目学习。正巧今天看文章时读到 鱼皮老哥哥 的一篇文章【这本免费小书，带你征服 GitHub！】以此学习记录。

本人目前大三，只能以大三一名学生的视角和理解来阅读和学习这一篇文章，可能思维想法些许稚嫩，那就总结跟随优秀的前任步伐，总结经验叭。详情一定要阅读原作者的原文呀！！

阅读 GitHub 漫游指南 原文

Github 项目

Github 上创建项目的维度

快速上手框架来实战，即 demo（学习视频、文章等）
重构别人的代码
创建自己可用的框架
快速构建大型应用
构建通用的框架

好像易上手的项目更受大家欢迎👏

项目如何成长

重点是测试，更多测试，试测试测试试测试测试

会接触更多的东西，如 stub，如 mock，如 fakeserver。

取一个好名字

有意义的名字
简单符合项目的名字
个性化维持自己一定的命名规则

挑选好 LICENSE

为了防止自己的软件被竞争对手所使用，大多数厂家停止分发其软件源代码，并开始使用版权和限制性软件许可证，来限制或者禁止软件源代码的复制或再分配。

随后，便诞生了开源软件的概念，开源的要求比自由软件宽松一些。迄今发布的自由软件源代码都是开源软件，而并非所有的开源软件都是自由软件。这是因为不同的许可（协议）赋予用户不同的权利，如 GPL 协议强制要求开源修改过源码的代码，而宽松一点的 MIT 则不会有这种要求。

简单 LICENSE 例子

GPL

由于 GPL 的传染性，便意味着，他人引用我们的代码时，其所写的代码也需要使用 GPL 开源。即：GPL 是有 “传染性” 的 “病毒” ，因为 GPL 条款规定演绎作品也必须是 GPL 的。

MIT

因此，一般而言，我使用的是 MIT 协议。至少我保留了一个署名权，即你可以修改我的代码，但是在 LICENSE 里必须加上我的名字。

选用 MIT 特别有意思，特别是在最近几年里，发生过：

总结

以后非商业的项目，我也要选用这个

Creative Commons

考虑到未来会以纸质书的形式出现，便会使用 CC-BY-NC-ND 协议：

CC -> Creative Commons
BY -> 署名（英语：Attribution，by）
NC -> 非商业性使用（英语：NonCommercial）
ND -> 禁止演绎（英语：NoDerivs）。

即，任何人可以使用我写的电子书来自由复制、散布、展示及演出，但是不得用于商业用途（作者本人可以）。它可以随意地放在他的博客上，他的各个文章里。但是必须标明出自，并且不得改变、转变或更改本作品。

如果你不介意的话，你可以使用公有领域（Public Domain）。可是这样一来，万一有一天，别人直接拿你的作品出书，你就骂爹了。（对！芜湖！）

总结

以后写文字类的东西，要选用这个

Git 基础和 Github 使用

Git

从一般开发者的角度来看，Git 有以下功能：

从服务器上克隆数据库（包括代码和版本信息）到单机上。
在自己的机器上创建分支，修改代码。
在单机上自己创建的分支上提交代码。
在单机上合并分支。
新建一个分支，把服务器上最新版的代码 fetch 下来，然后跟自己的主分支合并。
生成补丁（patch），把补丁发送给主开发者。
看主开发者的反馈，如果主开发者发现两个一般开发者之间有冲突（他们之间可以合作解决的冲突），就会要求他们先解决冲突，然后再由其中一个人提交。如果主开发者可以自己解决，或者没有冲突，就通过。
一般开发者之间解决冲突的方法，开发者之间可以使用 pull 命令解决冲突，解决完冲突之后再向主开发者提交补丁。

从主开发者的角度（假设主开发者不用开发代码）看，Git 有以下功能：

查看邮件或者通过其它方式查看一般开发者的提交状态。
打上补丁，解决冲突（可以自己解决，也可以要求开发者之间解决以后再重新提交，如果是开源项目，还要决定哪些补丁有用，哪些不用）。
向公共服务器提交结果，然后通知所有开发人员。

Github

百科说：

GitHub 是一个共享虚拟主机服务，用于存放使用Git版本控制的软件代码和内容项目。它由GitHub公司（曾称Logical Awesome）的开发者Chris Wanstrath、PJ Hyett和Tom Preston-Werner 使用Ruby on Rails编写而成。

官方说：

Millions of developers and companies build, ship, and maintain their software on GitHub—the largest and most advanced development platform in the world.

数以百万计的开发者和公司在全球最大、最先进的开发平台GitHub上构建、发布和维护他们的软件。

Git 与 Github

首先 Git 是一个分布式的版本控制系统，最初由Linus Torvalds编写，用作Linux内核代码的管理。在推出后，Git在其它项目中也取得了很大成功，尤其是在Ruby社区中。目前，包括Rubinius、Merb和Bitcoin在内的很多知名项目都使用了Git。Git同样可以被诸如Capistrano和Vlad the Deployer这样的部署工具所使用。

GitHub可以托管各种git库，并提供一个web界面，但与其它像 SourceForge或Google Code这样的服务不同，GitHub的独特卖点在于从另外一个项目进行分支的简易性。为一个项目贡献代码非常简单：首先点击项目站点的“fork”的按钮，然后将代码检出并将修改加入到刚才分出的代码库中，最后通过内建的“pull request”机制向项目负责人申请代码合并。已经有人将GitHub称为代码玩家的MySpace（这啥意思）

流行项目分析

例如 GitHub 上的 Star 大于 10 万的项目。（截止：2021年4月12日18时。）

约 25 个仓库结果

语言分布

Languages	number
JavaScript	6
Python	4
Java	2
C	1
C++	1
Dart	1
Rust	1
Shell	1
TypeScript	1

前十项目

项目名	Language	Star	Url
freeCodeCamp	JavaScript	323k	github.com/freeCodeCam…
996.ICU	Rust	256k	github.com/996icu/996.…
free-programming-books		183k	github.com/EbookFounda…
vue	JavaScript	182k	github.com/vuejs/vue
react	JavaScript	167k	github.com/facebook/re…
coding-interview-university		163k	github.com/jwasham/cod…
awesome		158k	github.com/sindresorhu…
tensorflow	C++	155k	github.com/tensorflow/…
developer-roadmap		154k	github.com/kamranahmed…
bootstrap	JavaScript	149k	github.com/twbs/bootst…

发现更多的是各种编程的学习资源，看来大家伙对于在 github 学习的趋势越来越明显了。

Pull Request

给其他的仓库来创建 Pull Request 来做贡献。

CLA

CLA 即 Contributor License Agreement，在为一些大的组织、机构提交 Pull Request 的时候，可能需要签署这个协议。他们会在你的 Pull Request 里问你，只有你到他们的网站去注册并同意协议才会接受你的 PR。

以下是我为 Google 提交的一个 PR

Google CLA

以及 Eclipse 的一个 PR

Eclipse CLA

构建 Github 项目

用好 GitHub

一个良好的 Github 项目，从测试到 CI,再到自动部署.

组成：

看板式管理应用程序（如 trello，简单地说就是管理软件功能）
CI（持续集成）
测试覆盖率
代码质量（code smell）

对于一个不是远程的团队（如只有一个人的项目）来说，Trello、Jenkin、Jira不是必需的：

测试

通常我们都会找说明文档时，如果没有的话，更常见的是看测试。

作用：

我不希望每次做完一个个新功能的时候，再手动地去测试一个个功能。（自动化测试）
我不希望在重构的时候发现破坏了原来的功能，而我还一无所知。
我不敢push代码，因为我没有把握。

看上去似乎每个测试都很小，不过补完每一个测试之后我们就得到了测试覆盖率

File	Statements	Branches	Functions	Lines
lettuce.js	98.58% (209 / 212)	82.98%(78 / 94)	100.00% (54 / 54)	98.58% (209 / 212)

CI

CI 对于一个开发者在不同城市开发同一项目上来说是很重要的，这意味着当你添加的部分功能有测试覆盖的时候，项目代码会更加强壮。

代码质量

像 jslint 和 eslint 这类的工具，只能保证代码在语法上是正确的，但是不能保证你写了一堆 bad smell 的代码。

重复代码
过长的函数
等等

Code Climate 是一个与 GitHub 集成的工具，我们不仅仅可以看到测试覆盖率，还有代码质量。

这就意味着我们可以对上面的代码进行重构，他们是重复的代码。我们可以进行一定地优化喔。

模块分离与测试

在之前说到

奋斗了近半个月后，将 fork 的代码读懂、重构、升级版本、调整，添加新功能、添加测试、添加 CI、添加分享之后，终于 almost finish。

今天就来说说是怎样做的，里面有：

代码质量（Code Climate）
CI状态（Travis CI）
测试覆盖率（96%）
自动化测试（npm test）
文档

按照 Web Developer 路线图来说，我们还需要有：

版本管理
自动部署
等等

代码模块化

在 SkillTree 的源码里，大致分为三部分：

namespace 函数：顾名思义
Calculator 也就是 TalentTree，主要负责解析、生成 url，头像，依赖等等
Skill 主要是 tips 部分。

就是要把代码进行模块化地管理，类似于 CommJS、AMD 规范、ES6 模块化或者使用我们工程师工具如 webpack、vite 等来进行代码模块化

自动化测试

写对应的自动化测试脚本
在 package.json 里添加脚本
这样当我们 push 代码的时候便会自动跑所有的测试
也可以配置对应需要测试的配置文件

测试示例

简单地看一下 Book 的测试：

/* global describe, it */

var requirejs = require("requirejs");
var assert = require("assert");
var should = require("should");
requirejs.config({
  baseUrl: 'app/',
  nodeRequire: require
});

describe('Book,Link', function () {
  var Book, Link;
  before(function (done) {
    requirejs(['scripts/Book'、], function (Book_Class) {
      Book = Book_Class;
      done();
    });
  });

  describe('Book Test', function () {
    it('should return book label & url', function () {
      var book_name = 'Head First HTML与CSS';
      var url = 'http://www.phodal.com';
      var books = {
        label: book_name,
        url: url
      };

      var _book = new Book(books);
      _book.label.should.equal(book_name);
      _book.url.should.equal(url);
    });
  });
});

因为我们用 require.js 来管理浏览器端，在后台写测试来测试的时候，我们也需要用他来管理我们的依赖，这也就是为什么这个测试这么长的原因，多数情况下一个测试类似于这样子的。（用 Jasmine 似乎会是一个更好的主意，但是用习惯 Jasmine 了）

describe('Book Test', function () {
it('should return book label & url', function () {
  var book_name = 'Head First HTML与CSS';
  var url = 'http://www.phodal.com';
  var books = {
    label: book_name,
    url: url
  };

  var _book = new Book(books);
  _book.label.should.equal(book_name);
  _book.url.should.equal(url);
});
});

最后的断言，也算是测试的核心，保证测试是有用的。

感觉自己不太熟悉测试这一类环节

Git 提交信息及几种不同的规范

谈谈一个好的 Git、SVN 提交信息是怎样规范出来的

在团队协作中，使用版本管理工具 Git、SVN 几乎都是这个行业的标准。当我们提交代码的时候，需要编写提交信息（commit message）。

而提交信息的主要用途是：告诉这个项目的人，这次代码提交里做了些什么。

并且防止一次修改中，修改过多的文件，导致后期修改、维护、撤销等等困难。

而对于不同的团队来说，都会遵循一定的规范，主要会介绍以下几种写法：

工作写法
常规写法
开源库写法

工作写法

当项目里，有一个唯一标识的 key，我们就可以使用 key 来规范我们的提交信息

[key] 提交人 & 开发者: do something

比如：[PHODAL-0001] ladohp & phodal: update documents，解释如下：

PHODAL-0001，该项目的 key，它可以帮我们找到某个业务修改的原因，即点出相应 bug 的来源
ladohp & phodal ，结对编程的两个人的名字，后者（phodal）一般是写代码的人，出于礼貌就放在后面了。由于 Git 的提交人只显示一个，所以写上两个的名字。当提交的人不在时，就可以问另外一个人修改的原因。
update documents，我们做了什么事情

缺点：而对于其他团队来说，并不知道对应 key 值这种东西，因此就需要一种额外的作法。

常规写法

对于我来说，我则习惯这种的写法：

[任务分类] 主要修改组件（可选）：修改内容

示例 1，[T] tabs: add icons 。

其中的 T 表示这是一个技术卡
tabs 表示修改的是 Tabs
add icons 则表示添加了图标。

示例 2，[SkillTree] detail: add link data。

SkillTree 表示修改的是技能树 Tab 下的内容
detail 则表示修改的是详情页
add link data 则表示是添加了技能的数据

这样做的主要原因是，它可以轻松也帮我 filter 出相应业务的内容。

缺点：要这样做需要团队达到一致，因此付出一些额外的约束成本。

开源应用、开源库写法（本人推荐）

与我们日常工作稍有不同的是：工作中的 Release 计划一般都是事先安排好的，不需要一些 CHANGELOG 什么的。而开源应用、开源库需要有对应的 CHANELOG，则添加了什么功能、修改了什么等等。毕竟有很多东西是由社区来维护的。

因此，这里以做得比较好的开源项目 Angular 为例展示。Angular 团队建议采用以下的形式：

<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

诸如：docs(changelog): update change log to beta.5 中：

docs 则对应修改的类型
changelog 则是影响的范围
subject 则是对应做的事件

对应的类型有：

build：影响构建系统或外部依赖关系的更改（示例范围：gulp，broccoli，npm）
ci：更改我们的持续集成文件和脚本（示例范围：Travis，Circle，BrowserStack，SauceLabs）
docs：仅文档更改
feat：一个新功能
fix：修复错误
perf：改进性能的代码更改
refactor：代码更改，既不修复错误也不添加功能
style：不影响代码含义的变化（空白，格式化，缺少分号等）
test：添加缺失测试或更正现有测试

同时还对应了 20+ 的 Scope，可以说这种提交比上面的提交更有挑战。

而这样做的优点是，它可以轻松地生成一个 CHANGELOG。与此同时还有一个名为 Conventional Commits 的规范，建议采用相似的形式。

目前我在项目中运用的最多的是 feat

创建项目文档

我们需要为我们的项目创建一个文档，通常我们可以将核心代码以外的东西都称为文档：

README
文档
示例
测试

README

README 通常会显示在 GitHub 项目的下面，当创建仓库的时候也会建议添加。

通常在这个 README 里，还会有：

项目简介
针对人群
安装指南
示例
运行的平台
如何参与贡献
协议

官方首页与在线文档

很多开源项目都会有自己的网站，并在上面有一个文档，而有的则会放在readthedocs.org/。

在一个开源项目中，良好和专业的文档是相当重要的，有时他可能会比软件还会重要。因为如果一个开源项目好用的话，多数人可能不会去查看软件的代码。这就意味着，多数时候他在和你的文档打交道。

文档一般会有：API 文档、配置文档、帮助文档、用户手册、教程等等

写文档的软件有很多，如 Markdown、Doxygen、Docbook 等等。

可用示例

一个简单上手的示例非常重要，特别是通常我们是在为着某个目的而去使用一个开源项目的是时候，我们希望能马上使用到我们的项目中。而不是需要繁琐的步骤才能进行下一步。

改善 GitHub 项目代码质量：重构

每个程序员都不可避免地是一个 Coder，一个没有掌握好技能的 Coder，算不上是手工艺人，但是手工艺人，需要有创造性的方法。

为什么重构？

为了更好的代码。

修 Bug 需要更好的技术。
如果你没办法理解当时为什么这么做，你的修改只会带来更多的 Bug。
写代码容易，读代码难。

假设我们写这些代码只要半天，而别人读起来要一天。为什么不试着用一天的时候去写这些代码，让别人花半天或者更少的时间来理解。

如果你的代码已经上线，虽然是一坨坨的。但是不要轻易尝试没有测试的重构。

一般重构方法

Rename

重命名且语义化，更好理解和维护。

Extract Method

扩展方法：将方法扩展模块组件化，更易理解以及追踪维护。

Inline Method

内联方法：与扩展方法相对应，在分割的代码中，若扩展方法没有多余必要，或需将方法写一起更易理解，那么推荐使用内联方法。

如何推广

擅长编写 md 电子书来攒 Star
开源并不是你把软件、README 写好就行了，还有详细的文档、示例程序等等。
开源也不是你的项目好了，就会有一堆人参与进来。
开源还要你帮助别人解决 Bug，……。

Marketing First

Vue 不是因为好用，而一下子火了。这一点我印象特别深，当时在 GitHub Trending 上看到了这个项目，发现它还不能很好地 work。

而如文章《FIRST WEEK OF LAUNCHING VUE.JS》所说，项目刚开始的时候作者做了一系列的营销计划：

HackerNews
Reddit /r/javascript
EchoJS
The DailyJS blog
JavaScript Weekly
Maintain a project Twitter account（维护项目的 Vue 账户）

除此，文中还提到了一篇文章《How to Spread The Word About Your Code》。

要在不同的社会平台，介绍并且宣传以及提供功能。国内比较好的平台有：

掘金
极客头条
开发者头条
v2ex
知乎
不成器的微博

编写一个好的 README

在一个开源项目里，README 是最重要的内容。它快速地介绍了这个项目，并决定了它能不能吸引用户：

这个项目做什么？
它解决了什么问题
它有什么特性
hello, world 示例

这个项目做什么——一句话文案

这一句话，必须简单明了也介绍，它是干什么的。

如 Angular 的一句话方案是：One framework. Mobile & desktop.

而 React 是：A declarative, efficient, and flexible JavaScript library for building user interfaces.

Vue 则是：A progressive, incrementally-adoptable JavaScript framework for building UI on the web.

它解决了什么问题

在一句话文案之后，在描述中，写出它能解决什么问题。

它有什么特性

当我们有 A、B、C 几个不同的框架的时候，作为一个开发人员，就需要对比他们的特性。

安装及 hello, world 示例

在我们看完了上面的介绍之后，要接一个简单的安装教程和 hello, world 的示例。

技术文档

好了，依一个开发人员的角度，如果上面的步骤一切顺利的话，接下来，便是使用这个开源项目来完成我们的功能。这个时候，我们开始转移注意力到文档上了。

技术文档

对于一个复杂的开源项目来说，文档上要写明安装、编译、配置等等的过程。

编写技术文章、书籍

到目前为止，我们做了一系列 markdown 相关的工作，却也还没有结束。要知道只有真正写过一系列开源项目的人，才能体会到什么是 markdown 程序员~~。

官方文档，一般要以比较正式的口吻来描述过程，这种写法相当的压抑。

如果要用轻松诙谐的口气，那么就可以写一系列的技术文章。

假如这是一个前端框架，那么我们可以介绍它如何与某个后端框架配合使用；又或者是，它与某个框架的对比等等。

鼓励、吸引贡献者

要吸引其它开发人员来到你的项目，不是一件容易的事。

你需要不断地鼓励他/她们，并适时地帮他/她们解决问题，以避免他/她们在提 pull request 的过程中放弃了。

这一点特别的有意思，当有一个开发人员发现了项目中的 bug，那么他/她会尝试去解决这个问题。与此同时，他/她还会为你的项目带来 pull request，但是在这个过程中，因为测试等等的问题，可能会阻碍他的 PR。这个时候，就需要我们主要去提示/教他们怎么做，又或者是帮他/她们解决完剩下的问题。那么，下次他/她提一个 PR 的时候，他/她就能解决问题了。

Git 与 GitHub 工具推荐

Git 命令行增强

diff-so-fancy

git-extras

Ubuntu

$ sudo apt-get install git-extras

Mac OS X with Homebrew

$ brew install git-extras
$ git-summary


 project  : github-roam
 repo age : 2 years, 7 months
 active   : 40 days
 commits  : 124
 files    : 101
 authors  :
    72  Fengda HUANG  58.1%
    29  Fengda Huang  23.4%
     8  Phodal HUANG  6.5%
     3  Phodal Huang  2.4%
     2  yangpei3720   1.6%
     2  WangXiaolong  1.6%
     2  TZS           1.6%
     1  安正超        0.8%
     1  Li            0.8%
     1  Qiuer         0.8%
     1  SCaffrey      0.8%
     1  oncealong     0.8%
     1  zminds        0.8%

Git、GitHub桌面增强

SourceTree

GitHub Desktop

如何在 GitHub “寻找灵感（fork）”

重造轮子是重新创造一个已有的或是已被其他人优化的基本方法。

需求

要一直询问自己为啥需要着一些别人项目中的需求

如

为什么我只需要 jQuery 里的选择器、Ajax 要引入那么重的库呢？
为什么我只需要一个 Template，却想着用 Mustache
为什么我需要一个 Router，却要用 Backbone 呢？
为什么我需要的是一个 isObject 函数，却要用到整个 Underscore？

计划

这时候我参考了一本电子书《Build JavaScript FrameWork》，加上一些平时的需求，于是很快的就知道自己需要什么样的功能：

Promise 支持
Class类（PS：没有一个好的类使用的方式）
Template 一个简单的模板引擎
Router 用来控制页面的路由
Ajax 基本的 Ajax Get/Post 请求

在做一些实际的项目中，还遇到了这样的一些功能支持：

Effect 简单的一些页面效果
AMD 支持

而我们有一个前提是要保持这个库尽可能的小、同时我们还需要有测试。

实现第一个需求

简单说说是如何实现一个简单的需求。

生成框架

因为 Yeoman 可以生成一个简单的轮廓，所以我们可以用它来生成这个项目的骨架。

Gulp
Jasmine

寻找

在 GitHub 上搜索了一个看到了下面的几个结果：

但是显然，他们都太重了。事实上，对于一个库来说，80% 的人只需要其中 20% 的代码。

然后借鉴代码或原生代码来实现我们的功能

如何以“正确的姿势”阅读开源软件代码

所有让你直接看最新源码的文章都是在扯淡，你应该从“某个版本”开始阅读代码。

我们并不建议所有的读者都直接看最新的代码，正确的姿势应该是：

clone 某个项目的代码到本地
查看这个项目的 release 列表
找到一个看得懂的 release 版本，如 1.0 或者更早的版本
读懂上一个版本的代码
向后阅读大版本的源码
读最新的源码

最好的在这个过程中，可以自己造轮子来实现一遍。

GitHub 寻宝指南

作为一个资深的咨询师、程序员，GitHub 是我用过的最好工具，GitHub 是一个宝藏库，可没有藏宝图，GitHub 一1亿的仓库也和你没有关系。这么一些年下来，也算是掌握了一定的技巧，写篇文章记录一下，也就顺其自然了。

总结一句话便是：GitHub 来搜索 Google 搜索不到的。它们可以 work 的原因，都是因为我们想做的事情，已经有人已经走过。如果你走的是一条新的路，那么这篇文章对你来说，意义可能没有那么大。

寻找 Demo 节省时间

技术栈的关键字搜索，并按更新时间进行排序，以查找是否有合适的 Demo。

温馨提醒：对于简单的项目来说，自己直接写 Demo 会更加方便。 尝试项目需要成本，若是需要尝试使用多个项目，那么有可能就浪费时间。

寻找脚手架：加快前期开发

温馨提醒：我们需要衡量：修改脚手架的成本，是否比自己重头写快。

寻找 awesome-xxx：探索可能性

练习新的框架，我总习惯于，编写一系列相关的 DEMO 项目，然后使用 awesome-xxx 探索可能性。

Awesome-xxx 系列，是 GitHub 上最容易赚 Star 的类型。

在这样的项目里，都以一定的知识体系整理出来的，从索引和查阅上相应的方便。如果你想进入一个新的领域，会尝试新的东西就搜索 awesome xxx 吧。

温馨提醒：awesome-xxx 只意味着它们包含尽可能多的资料，并不代表它们拥有所有相关的库。

模仿轮子的轮子

学习一个成熟的框架，直接阅读现有源码的成本太高，毕竟也不经济。

最好的方式，就是去造轮子。从模仿轮子之上，再去造轮子，是最省力气的方式。再配合《造轮子与从Github生成轮子》一文，怕是能写一系列的框架。而造一个相似轮子的想法，往往很多人都有。尤其是一个成熟的框架，往往有很多仿制品。

于是，当你想了解一个框架，造个轮子，不妨试试搜索 xxx-like 或者 xxx-like framework，中文便是 仿 react 框架 或者 类 react。如我们在 Google 上搜索 react-like 就会搜索到 inferno。不过，按 GitHub 的尿性，要搜索到这样的框架，并不是一件容易的事。这时 Google 往往比 GitHub 搜索好用。

所以建议：平时上班休息时，搜索相关的轮子，回家就可以造轮子了。

学习资源

GitHub 上拥有大量的学习资源，从各类的文章到笔记，还有各式各样的电子书。如：

只需要搜索：类型 + 笔记，如 操作系统笔记 就能找到一些操作系统相关的笔记。
只需要搜索：书名 就能找到一些和这本书相关的资源，如 重构改善既有代码的设计。

与此同时，GitHub 上还会搜索到各种 未经授权英文书籍的翻译，又或者是各种电子书的 PDF 版。作为多本书的作译者，当然不鼓励 GitHub 上找到一些盗版书。

而在 GitHub 上又有一些库，可以提供相应的学习资源，如 free-programming-books-zh_CN，即免费的编程中文书籍索引。

建议：请尊重版权，哈哈哈。

GitHub 获 Star 指南

每天打开 GitHub Trending，都是各种面试指南，这样的生活真难受。如果你的项目是金子，那么请读读这篇文章。

为什么我们 Star 一个项目

在 GitHub 获得 Star 的重点是，碰触人们的 G 点——人们只对和自己有关的事情感兴趣。或是证明自己是对这个感兴趣，或是觉得这个项目不错可以收藏，或者是觉得作者不容易鼓励一下作者。
获得 Star 的核心是：你有人们想要的东西，你分享了人们想要的内容。

GitHub 流量分析

流量主要来源于几部分：

GitHub 项目的直接访问
GitHub 的直接访问
来源于知乎等社交网站的
来自于 GitHub Pages 的访问
来自其它社交网站的访问

大抵原因有两个：

用户看的都是 GitHub Pages 上的内容
从数量上来看，受众并不多

核心的部分：你分享了人们想要的代码、内容。否则，你带来了大量的流量，并不一定能转化为你想要的关注度。

GitHub 获 Star 指南技巧

技巧一：结合 SEO 技巧

搜索引擎优化（Search Engine Optimization）。稍有不同的是，GitHub 在实践的过程中，帮助我们优化了很多细节。它可以让我们更关注于核心的要素。

若是想获得来自于 Google 等搜索引擎的访问，那么要掌握的技巧有：

简单实用的项目名。项目名在 Google 搜索结果里是放在最前面的部分，它与 URL 同在。
写好项目的 Description。不管怎样，你一定要为你的项目写好 Description，让看到的人知道它在做什么。
设置好相应的 topics。GitHub 为项目设计了一个 Topics 页面，这些页面会被拉入相应的索引中，可以从 Google 等搜索引擎和 GitHub 中搜索到。
作为外链加入文章中。作为 SEO 技巧的一部分，你需要在你的博客和文章里，适当地引用你的 GitHub 项目，它会你的项目带来流量。
合适的外链标题。作为链接存在时，需要注意链接的标题（与项目主题一致），它会在某种程度上影响搜索结果。

这些只是一些基本的内容，算不上是技巧，但是做好基础很重要。

技巧二：完整、易读的 README

让我们再强调一下，好的 README 真的很重要，重要、重要！重要。

GitHub 是一个人的简历，而开源项目的 README，就好像是一个项目的简历。在这份简历里，你需要好好地写你的项目：

这个项目做什么？？
它解决了什么问题？
它有什么特性 — hello, world 示例？
怎么使用这个项目？
这个项目使用的是什么协议，是否允许商用？

技巧三：社交分享

分享频率，要适度，适量。

技巧四：文章

既然我写了一个这么好的开源项目，那么最好的方式，还是写一篇文章介绍一下这个项目吧。blabla，写完了一篇项目的使用文档：

为什么需要这个项目？
这个项目是什么？
这个项目能解决什么问题？
这个项目要怎么用啊？

技巧五：把握 GitHub Trending

万一，我是说万一，你的项目上了 GitHub Trending。截个图，然后你可以再写一篇文章（我的项目是如何上 GitHub Trending，毕竟上 Trending 很简单），发一条微博，写一个想法，录个小视频，大家快来看这是我的项目。

理论上上 GitHub Trending 会吸引来更多的用户——有大量的网站、自动化微博等，会每天去介绍这些新的上的 Trending 项目，没有意外的话，它会为你带来更多的流量——意味着更多的关注度。

不是技巧的技巧：持续性

事实上，如你所知，我在 GitHub 上获得大量 Star 的原因，并不是说我有一个优秀的项目。而在于我在持续的更新，持续不断地在 GitHub 上做自己喜欢的项目，投入时间分享相关的技巧，还有一系列相关的开源项目。

我们一直在持续变好，打造一个自由的互联网世界，打造一个个自己喜欢的工具。

最后

笔者看完这一篇 GitHub 漫游指南感觉找到一个新的方向或者说是开阔视野吧。实际起来其实对于目前在校生的我还是有些许困难和难以理解，那就兴趣使然，个人习惯于让压力使自己驱动起来。开始计划计划！

4.15记 - Github 漫游指南阅读有感

前言

Github 项目

Github 上创建项目的维度

项目如何成长

取一个好名字

挑选好 LICENSE

简单 LICENSE 例子

GPL

MIT

总结

Creative Commons

总结

Git 基础和 Github 使用

Git

Github

Git 与 Github

流行项目分析

语言分布

前十项目

Pull Request

CLA

构建 Github 项目

用好 GitHub

测试

CI

代码质量

模块分离与测试

代码模块化

自动化测试

测试示例

Git 提交信息及几种不同的规范

工作写法

常规写法

开源应用、开源库写法（本人推荐）

创建项目文档

README

官方首页与在线文档

可用示例

改善 GitHub 项目代码质量：重构

为什么重构？

一般重构方法

Rename

Extract Method

Inline Method

如何推广

Marketing First

编写一个好的 README

这个项目做什么——一句话文案

它解决了什么问题

它有什么特性

安装及 hello, world 示例

技术文档

技术文档

更多的示例程序

编写技术文章、书籍

鼓励、吸引贡献者

Git 与 GitHub 工具推荐

Git 命令行增强

diff-so-fancy

git-extras

Git、GitHub桌面增强

SourceTree

GitHub Desktop

如何在 GitHub “寻找灵感（fork）”

需求

计划

实现第一个需求

生成框架

寻找

如何以“正确的姿势”阅读开源软件代码

GitHub 寻宝指南

寻找 Demo 节省时间

寻找脚手架：加快前期开发

寻找 awesome-xxx：探索可能性

模仿轮子的轮子

学习资源

GitHub 获 Star 指南

为什么我们 Star 一个项目

GitHub 流量分析