Merge pull request #139 from YunxiangHuang/fix_zh-CN_typo

Fix some typos of zh-CN version

source/zh-CN/0.3.0/index.html.haml

@@ -24,12 +24,12 @@ version: 0.3.0
   为了让用户和开发人员更好知道每一个版本有哪些区别。
 
   ### 为何我要在乎呢？
-  因为归根结底软件是为人提供的。既然你不关心人，哪么为何写软件呢？
+  因为归根结底软件是为人提供的。既然你不关心人，那么为何写软件呢？
   多少你还是要关心你的受众。
 
   本文档原作者和另外两个人的一个[播客][thechangelog]向大家介绍了，
   为何代码的管理者和开发者应该在乎更新日志。如果你有一小时时间和很好的英文听力本领，
-  不放听听。
+  不妨听听。
 
   ### 怎么定义好的更新日志
   好问题！
@@ -56,7 +56,7 @@ version: 0.3.0
 
   ### 怎么尽可能减少耗费的精力？
   永远在文档最上方提供一个'Unreleased' 未发布区域，来记录当前的变化。
-  这佯作有两大意义。
+  这样作有两大意义。
 
   - 大家可以看到接下来会有什么变化
   - 在发布时，只要把'Unreleased'改为当前版本号，然后再添加一个新的'Unreleased'就行了
@@ -74,7 +74,7 @@ version: 0.3.0
 
   ### 世界上不是有标准的更新日志格式吗？
   貌似GNU或者GNU NEWS还是提过些规范的，事实是它们太过简陋了。
-  开发有那么多中情况，采用那样的规范，确实是不太合适的。
+  开发有那么多种情况，采用那样的规范，确实是不太合适的。
 
   这个项目提供的[规范][CHANGELOG]是作者本人希望能够成为世界规范的。
   作者不认为当前的标准足够好，而且作为一个社区，我们是有能力提供更棒的规范。
@@ -92,15 +92,15 @@ version: 0.3.0
 
   ### 为何不直接记录`git log`?
 
-  因为git日志一定是乱糟糟的。哪怕一个最理想的由完美的程序员开发的提交的，哪怕一个
-  从不忘记每次提交全部文件，不写错别字，不忘记重构每一个部分——也无法保证git日志完美无瑕。
+  因为git日志一定是乱糟糟的。哪怕一个最理想的由完美的程序员开发和提交的，哪怕一个
+  从不忘记每次提交全部文件，不写错别字，不忘记重构每一个部分，也无法保证git日志完美无瑕。
   况且git日志的核心在于记录代码的演化，而更新日志则是记录最重要的变更。
 
   就像注释之于代码，更新日志之于git日志。前者解释*为什么*，而后者说明*发生了什么*。
 
 
   ### 更新日志能机器识别吗？
-  非常困难，因为有各种不同的文件格式和其他规范。
+  非常困难，因为有各种不同的文件格式和其它规范。
 
   [Vandamme][vandamme]是一个Ruby程序（由[Gemnasium][gemnasium]团队制作），可以解析
   好多种（但绝对不是全部）开源库的更新日志。