Github 与代码质量管理

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

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

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

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)。

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

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

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

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

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

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

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

我来评几句
登录后评论

已发表评论数()

相关站点

+订阅
热门文章