revise 7 rules for git workflow

Author: ying.liu

git-workflow.md

@@ -6,7 +6,7 @@
 
 分支类型：
 
-- release 分支：该分支在第一次上线之后，永远保持可随时上线状态，不允许直接在这个上面进行更改或者提交代码，只能从其他分支 merge
+- release 分支：该分支在第一次上线之后，永远保持可随时上线状态，不允许直接在这个上面进行更改或者提交代码，只能从其他分支 merge。通过权限设置保持 `release` 分支中的代码稳定性。
 - master 分支：master 分支主要用于新版本的开发，代码第一次上线时，从 master 创建出 release 分支用于上线发布。所有后期版本开发都在 master 分支上进行。版本开发完毕之后，上线前，将 master 的修改合并到 release，并做上线测试
 - 功能分支：每个版本的开发，会有很多独立功能，每个独立功能的开发，从 master 创建一个功能分支，并在功能分支上进行功能的开发，最后变基合并到 master。
 - hotfix 分支：这种类型的分支是针对线上 bug 的紧急 fix，直接从 release 创建分支。修复，测试完毕之后，合并到 release 上线。然后相应应该也并入 master 分支。
@@ -15,51 +15,51 @@
 
 - PR 每个 PR 都只是针对一个功能，不能够太大, 原则上不超过 10 个文件
 
-## 1. 基本规则
+## 1. 七条基本规则
 
-这里有一套规则要牢记：
+这里有七条基本规则需要牢记和遵守：
 
-- 在功能分支中执行开发工作。
+- 规则一：保护您的 `master`，尤其是 `release` 分支改动需要特别授权。
 
 为什么
 
-> 因为这样，所有的工作都是在专用的分支而不是在主分支上隔离完成的。它允许您提交多个 合并请求 pull request（PR）而不会导致混乱。您可以持续迭代提交，而不会使得那些很可能还不稳定而且还未完成的代码污染 master 分支。
+> 这样可以保护您的生产分支免受意外情况和不可回退的变更。所有代码需要 PR review 后才能并入这二个分支。
 
-- 从 `master` 独立出分支 `release` 分支用于上线发布。
+- 规则二：在功能分支中执行开发工作。
 
 为什么
 
-> 这样，您可以保持 `release` 分支中的代码稳定性，随时可以直接用于发布。
+> 因为这样，所有的工作都是在专用的分支而不是在主分支上隔离完成的。它允许您提交多个合并请求 `pull request`（PR）而不会导致混乱。您可以持续迭代提交，而不会使得那些很可能还不稳定而且还未完成的代码污染 master 分支。
 
-- 永远也不要将分支（直接）推送到 `master` ，请使用合并请求（Pull Request）。
+- 规则三：请使用合并请求（Pull Request）将功能分支合并到 `master`。不允许直接合并。
 
 为什么
 
 > 通过这种方式，它可以通知整个团队他们已经完成了某个功能的开发。这样开发伙伴就可以更容易对代码进行 code review，同时还可以互相讨论所提交的需求功能。
 
-- 在推送所开发的功能并且发起合并请求前，请更新您本地的`master`分支并且完成交互式变基操作（interactive rebase）。
+- 规则四：在发起合并请求之前，请确保您的功能分支可以成功构建，并已经通过了所有的测试（包括代码规则检查）。
 
 为什么
 
-> rebase 操作会将功能合并到被请求合并的 master 分支，并将您本地进行的提交应用于所有历史提交的最顶端，而不会去创建额外的合并提交（假设没有冲突的话），从而可以保持一个漂亮而干净的历史提交记录。 [合并（merge）和变基（rebase）的比较](https://www.atlassian.com/git/tutorials/merging-vs-rebasing)
+> 因为您即将将代码提交到这个稳定的分支。而如果您的功能分支测试未通过，那您的目标分支的构建有很大的概率也会失败。此外，确保在进行合并请求之前应用代码规则检查。因为它有助于我们代码的可读性，并减少格式化的代码与实际业务代码更改混合在一起导致的混乱问题。
 
-- 请确保在变基(rebase)并发起合并请求之前解决完潜在的冲突，合并分支后删除本地和远程功能分支。
+- 规则五：在发起合并请求 PR 前，请更新您本地的`master`分支并且完成交互式变基操作（interactive rebase）。发起 PR 之前解决完潜在的冲突
 
 为什么
 
-> 如果不删除需求分支，大量僵尸分支的存在会导致分支列表的混乱。而且该操作还能确保有且仅有一次合并到`master`。只有当这个功能还在开发中时对应的功能分支才存在。
+> rebase 操作会将功能分支合并到被请求合并的 master 分支，并将您本地进行的提交应用于所有历史提交的最顶端，而不会去创建额外的合并提交（假设没有冲突的话），从而可以保持一个漂亮而干净的历史提交记录。 [合并（merge）和变基（rebase）的比较](https://www.atlassian.com/git/tutorials/merging-vs-rebasing)
 
-- 在进行合并请求之前，请确保您的功能分支可以成功构建，并已经通过了所有的测试（包括代码规则检查）。
+- 规则六：请确保在 PR 合并分支后删除本地和远程功能分支。
 
 为什么
 
-> 因为您即将将代码提交到这个稳定的分支。而如果您的功能分支测试未通过，那您的目标分支的构建有很大的概率也会失败。此外，确保在进行合并请求之前应用代码规则检查。因为它有助于我们代码的可读性，并减少格式化的代码与实际业务代码更改混合在一起导致的混乱问题。
+> 如果不删除需求分支，大量僵尸分支的存在会导致分支列表的混乱。而且该操作还能确保有且仅有一次合并到`master`。只有当这个功能还在开发中时对应的功能分支才存在。
 
-- 保护您的 `master`，尤其是 `release` 分支改动需要特别授权。
+- 规则七：给出清晰的提交信息（commit message）。具体要求参见后门的建议。
 
 为什么
 
-> 这样可以保护您的生产分支免受意外情况和不可回退的变更。
+> 这些信息给出清晰的开发历史和版本发布信息。有很大的代码维护价值。
 
 ## 2. 建议的工作流