提升代码质量可以通过 Merge request + Code review 来做, 但是在实施中会遇到一些问题, 在这里梳理出一个流程来清晰整个过程
业务需求
- 从 develop checkout 出来需求分支 feature (TBD: 分支命名策略)
- 在该需求分支上面进行需求开发, (TBD: 是否在开始开发需求的时候就将 MR 发起并将其指给 Review 人)
- 在该分支上面需求不断的被完善, 然后自测
- 自测 OK, 这时候想要发到测试环境, MR 发起, 指给 Review 人, 等待 Review
- Review 人 review 代码, 给出建议, 然后讨论, MR 发起人修改. 直至 Review 人 LGTM
- MR 发起人可以进行 Merge 操作(TBD: 是否需要移除当前分支), 然后自行将其发至测试环境
- 交给 QA 进行测试
- QA 测试反馈
- 从 develop checkout 测试反馈修复分支(TBD: 分支命名策略)
- 在该反馈分支上面修复反馈的问题, 自测通过
- 转至 第五步 -> 第七步
- 直至 QA 测试通过
以上的流程存在的问题
Q: 分支命名策略未定
A: 目前还未确定分支命名策略
Q: 比较大的需求在完成需求之后提起 MR, 代码量比较大, 而且又涉及很多的业务逻辑. 对于 Review 人是一种压力, 如何解决?
A: 目前还没有想到一个更好的办法来处理这个问题
Q: 每一次的反馈都从 develop 分支切出来新的分支, QA 有可能有好几轮的测试, 这样下来会有好多的分支用来修复同一个需求的 QA 反馈, 分支数量是否过多, 如何管理这些分支? 为什么需要每次修复 QA 反馈都切出来新的分支, 在同一个分支上面不行吗?
A: 希望 git 分支 develop 和 master 的发展线是比较完美的, 能看出来整个项目的发展流程, 不希望在其中有一些在开发者开发需求过程中的一些流水线般的 commit, 所以在 Merge Request 的时候会选择 Squash Commit, 一旦选择了 Squash Commit 并进行了 Merge 操作, 该分支就不能再提起 MR 了, 否则被 Squash Commit 的 commit 还是会再次出现在 MR 中. 但是这个流程确实是繁琐的, 值得商讨一个更好的办法