Merge pull request #32 from QinRoc/gh-pages

Fix typos

chapters/01-start-project.md

@@ -53,8 +53,6 @@
 
 这就意味着，对于拿到这些代码的其他人，他们想怎么修改就可以怎么修改。
 
-这取决于
-
 ### GPL
 
 由于 GPL 的传染性，便意味着，他人引用我们的代码时，其所写的代码也需要使用 GPL 开源。即：GPL 是有 “传染性” 的 “病毒” ，因为 GPL 条款规定演绎作品也必须是 GPL 的。
@@ -83,5 +81,5 @@
 
 即，任何人可以使用我写的电子书来自由复制、散布、展示及演出，但是不得用于商业用途（作者本人可以）。它可以随意地放在他的博客上，他的各个文章里。但是必须标明出自，并且不得改变、转变或更改本作品。
 
-如果你不介意的话，你可以使用公有领域（Public Domain）。可是这样一来，万一有一天，别人直接拿的作品出书，你就骂爹了。
+如果你不介意的话，你可以使用公有领域（Public Domain）。可是这样一来，万一有一天，别人直接拿你的作品出书，你就骂爹了。
 

chapters/04-commit-message.md

@@ -90,5 +90,5 @@ Git 提交信息及几种不同的规范
 
 （以上的 10 个类型，感谢 Google Translate 提供的快速翻译支持）
 
-而这样做的优点是，它可以轻松地生成一个 CHANGELOG。与些同时还有一个名为 ``Conventional Commits`` 的规范，建议采用相似的形式。
+而这样做的优点是，它可以轻松地生成一个 CHANGELOG。与此同时还有一个名为 ``Conventional Commits`` 的规范，建议采用相似的形式。
 

chapters/06-refactor-project.md

@@ -60,7 +60,7 @@ regexobject: {
     code: /\s\`\`\`\n?([^`]+)\`\`\`/g
 ```
 
-他会匹配对应的Markdown类型，随后进行替换和处理。而``str```，就是管理口的输入和输出。
+他会匹配对应的Markdown类型，随后进行替换和处理。而``str``，就是管理口的输入和输出。
 
 接着，我们就可以对其进行简单的重构。
 

chapters/08-github-marketing.md

@@ -54,7 +54,7 @@ Vue 不是因为好用，而一下子火了。这一点我印象特别深，当
  - **这个项目做什么？**
  - **它解决了什么问题**
  - **它有什么特性**
- — **hello, world 示例**
+ - **hello, world 示例**
 
 ### 这个项目做什么——一句话文案
 
@@ -84,7 +84,7 @@ Vue 则是：A progressive, incrementally-adoptable JavaScript framework for bui
 
 ### 它有什么特性
 
-当我们有 A、B、C 几个不同的框架的时候，作为一个开发人员，就需要对比他们的特性，。如下是 Go 语言实现的 MQTT 示例：
+当我们有 A、B、C 几个不同的框架的时候，作为一个开发人员，就需要对比他们的特性。如下是 Go 语言实现的 MQTT 示例：
 
 ![GO MQTT 示例](./img/go-mqtt.png)
 

chapters/15-milestone.md

@@ -7,13 +7,13 @@ GitHub 里程碑
 >  Star 虽好，可不要贪杯哦。
 > 两年前在做 Annual Review 订下一年的目标时，想着写一个开源框架。去年订下今年的目标时，仍然继续着这样的想法。今年又要制定下一年的目标，2333~~。
 
-不久前，在 GitHub Ranking 上看到自己的 star 数（star 不是设计用于做“点赞”的，而是用来收藏的）时，发现已经快 20000 了。然后把自己的项目过了一遍，发现没有一个比较好的**代表性框架，**要么是应用，要么是电子书。
+不久前，在 GitHub Ranking 上看到自己的 star 数（star 不是设计用于做“点赞”的，而是用来收藏的）时，发现已经快 20000 了。然后把自己的项目过了一遍，发现没有一个比较好的**代表性框架**，要么是应用，要么是电子书。
 
 前 8 个项目里，除了 Growth 应用以外，其他的都是电子书内容——六本电子书加起来的 star 数有 **10619**，果然是骗 star 的。我只能尽力地去想想：为什么事情会变成这样了？
 
 ### 从创建开源框架说起
 
-创建开源框架和创建创建开源项目是不一样的，前者你服务于开发者，后者你服务于用户。
+创建开源框架和创建开源项目是不一样的，前者你服务于开发者，后者你服务于用户。
 
 两年前在做 Annual Review 的时候，想着未来的一年里可以做一个开源框架试试。那时刚毕业不久，对开源世界的各种游戏规则不是很了解：**开源并不是将代码提交上去，然后就会一下子火起来**。虽然我们可以在短期内赚上一些眼球，但是真正要将它采用到项目上的人不多。
 

chapters/18-get-star.md

@@ -28,7 +28,7 @@ GitHub 是一个非常有意思的地方，也常常变得非常有争议。有
 
 ## GitHub 流量分析
 
-实际了，当我们在说获得 star 的时候，我们说的是**为自己的项目做推广**。只是呢，获得 star 是其中的一个结果产物，也就是说，我们在宣传项目的过程中，获得了关注度。至于推广本身来说，不同的人会有不同的看法。
+实际上，当我们在说获得 star 的时候，我们说的是**为自己的项目做推广**。只是呢，获得 star 是其中的一个结果产物，也就是说，我们在宣传项目的过程中，获得了关注度。至于推广本身来说，不同的人会有不同的看法。
 
 事实上，GitHub 获取 star 与我们日常了解的营销差不多，先将用户吸引到我们的 GitHub 页面，再让用户有关注的动力（这一点太难了）。
 
@@ -126,7 +126,7 @@ GitHub 是一个人的简历，**而开源项目的 README，就好像是一个
 
 是不是写起来很简单？
 
-未来在其它的文章中，有一些相关的话题，便可以稍微提及一些相关的项目。比如，在这篇文章里，我还介绍了好几个近期的项目。这些文章，除了在我的公从号上，还会发在我的博客（累计 100 万访问量）上，我的知乎专栏上，还有我的……上。它们结合起来，会形成一股强大的力量，即能吸引用户，又能在 SEO 上有一定的提升。
+未来在其它的文章中，有一些相关的话题，便可以稍微提及一些相关的项目。比如，在这篇文章里，我还介绍了好几个近期的项目。这些文章，除了在我的公众号上，还会发在我的博客（累计 100 万访问量）上，我的知乎专栏上，还有我的……上。它们结合起来，会形成一股强大的力量，即能吸引用户，又能在 SEO 上有一定的提升。
 
 ### 技巧五：把握 GitHub Trending