Github 与代码质量管理

code-review-2.png

今天 SPlayerX 2018 已经超过 600 多个 Commits 了。这样的提交速度,对代码质量控制的压力很大。

坦白说,之前大部分项目一直很难落实代码审核(CodeReview)流程。对代码质量管理和代码审核(CodeReview),只能停留在提倡和靠自觉的阶段。

这次我启用了 Github 的 Branch Protection 功能,强制项目的所有代码都通过 Pull Request 的方式提交,经过 Review 流程后才能 Merge 合并的管理方式。结果配合利用自动化工具,节省了大量人为额外精力,真是异常的舒适顺畅。

11.png

Github 的分支保护(Branch Protection)功能曾经只是防止代码被 Force Push 清掉的防呆机制(Disables force-pushes to this branch and prevents it from being deleted.)。现在则加入了非常棒的辅助代码质量管理的功能,包括:

1. 强制所有提交都通过 Pull Request(Require pull request reviews before merging)。

22.png

启用后就不能再直接 Commit 和 Push 代码到被保护的分支上了。而且还能指定至少被几个开发者代码审核才能 Merge ,以及要求必须要项目的所有者(Owner)做代码审核后才能 Merge。

11-2.png

2. 必须通过第三方(例如持续集成 CI 服务、代码质量评估服务、测试覆盖率统计服务)状态检测后才能进行 Merge 合并(Require status checks to pass before merging)

11-5.png

这个功能非常赞。比如说 SPlayerX 2018 这个项目使用了 codecov 做测试覆盖率统计,和 travis 以及 appveyor 做持续集成 CI。现在我就可以保证每个  Pull Request 必须达到更高测试覆盖率标准和能编译成功(CI),否则就无法 Merge 合并。

11-6.png

3. 必须基于最新代码的 Pull Request 才能 Merge(Require branches to be up to date before merging)

4. 只有特定人员或开发者可以直接 Push 代码到被保护的 Branch (Restrict who can push to this branch)

11-6.png

这些自动化措施,可以在多人参与的项目中,技术上保证代码质量控制流程,减少人为的干扰。真是 Code Review 和 质量管控的利器。


另外,以目前的进度看,应该在8月中左右,新 SPlayerX 的 Alpha 版就可以开发好了。谢谢大家的支持