1. 成员需熟悉 SourceTree 的常规使用。包括 Pull, Push, Fetch, Checkout, Rebase, Rebase children of xxx interactively, Rebase current changes onto xxx-branch, Reset, Stash, Merge 等高频使用的操作
  2. 我们约定远端 master 分支（下面描述的 master 均指代远端 master 分支）总是安全可用的代码，未经验证的代码不能合并到 master（因此，未经验证的代码请勿提交 PR），master 分支的 commits 一经添加即不会消失，且不能被 force push（管理员需要为对应分支创建 Branch protection rule）
  3. 为了降低阅读和理解成本，请尽量让 master 分支保持一条直线（管理员需要去对应分支配置 Require linear history）
  4. 由于 master 分支是安全的，开发者若观察到 master 有更新，应尽早将本地开发分支 rebase 到 master 上方
  5. 团队成员在 Github 中心仓库中的代码滞后其本地开发的时间不能超过 12 小时。即每天修改的分支代码应 push 到中心仓库，以便其他成员感知，避免代码冲突
  6. 快速迭代，每个迭代分支都应是明确的功能，不宜过大；大功能应拆分，让依赖项能尽早合并到 master；总体来说，功能迭代启动开发到合并到 master，尽量在一周内完成
  7. Commit 日志参考 《Contributing to Angular - Commit Message Guidelines》，尽可能精确到其他阅读者无需继续询问该提交具体做了什么，禁止用 update 之类的连自己都看不懂做了啥的内容
  8. 如果觉得一句话无法描述修改内容，说明修改内容范围过大，可能需要拆分
  9. production 和 staging 的配置不得在版本控制中出现，杜绝密钥泄露及环境配置误用导致生产事故的可能性
  10. 另外，项目中应存在一份提供配置结构（而非内容）的 default 配置；development 配置由每位研发自行根据开发环境维护，同样不应在版本控制中出现