常规开发流程
1、将仓库 clone 到本地，已经 clone 的要 fetch & pull，保证本地 master 分支已经更新到最新状态
2、在 master 最新分支的基础上 checkout 一个开发分支，分支命名要求规范，如带用户名、日期、bug id 等关键信息
这里假定命名为 dev，操作命令为 git checkout -b dev
3、在 dev 分支上进行开发以及自测，并提交 Merge Request ，经组内人员 review 没问题后进入 QA 测试环节
4、测试过程发现的 bug fix 代码提交到 dev 分支上，经 QA 回归后进入待发布环节
在开始从 master checkout 出来 dev 分支的时间，到 dev 通过 QA 验收待发布期间，master 分支可能已经多次 merge 了其他同事的开发分支
因此，在待发布环节，需要将最新的 master 合并到自己的 dev 开发分支上 git merge master
5、待发布环节 merge 主干的最新代码后，如果有冲突需要首先解决冲突，并评估冲突对当前版本的影响，决定是否需要重新进行 QA 测试
6、在已经 merge 了最新代码的 dev 分支下，编译版本，安排灰度上线，观察线上业务是否正常（不正常需要回退线上版本）
7、发布完毕，告知 leader 将 dev 开发分支合并入 master
8、leader 合并 dev 分支到 master 分支，至此一个迭代版本的阶段开发完毕
社区版和企业版
在 github 上建立两个仓库，一个 public 仓库作为社区版本，一个 private 仓库作为企业版本
这两个仓库可以是基于同一个账户的，也可以是不同账户的两个仓库，如仓库名分别为 test-community 和 test-enterprise
在本地建立一个代码仓库 test，并添加两个远端 community 和 enterprise 分别指向两个不同的仓库
本地仓库建立两个分支，如 community-dev 和 enterprise-dev，根据开发建立子分支进行开发
开发完毕后合并入对应的版本分支
在发布到 github 的时候，push 分别指定远端和分支名
如 community 指示的是远端仓库 https://github.com/qc7even/test-community.git，community-dev 是分支名
