作者:张新
团队成员应该积极主动去领取任务,并且将相应的 Story 分配给自己,做好前期技术需求调查,或者是由 Team Lead 分配相应的任务给团队成员
做相应 Story 的人必须与其他同事(后端,PM, QA, etc.)一起过一下业务需求,并且尽早提前调查,越早越好。必须保证什么是我们将要做的。有任何问题,如果有必要随时去找 PM/QA 并且需要添加你的子任务到 Story 中。
建议以 姓名-ticket-简短描述命名你的 feature brnach,比如,shantinggui-supplyChain-ad。
这样做的话,我们就可以隔离我们的开发代码在一个特定分支上,而不是在我们的主分支上,从而保证主分支是随时可以发布的。
一旦 Story 分配至相应开发人员,Story 的开发人员必须清楚知道自己是 Owner,如果用了 Jira,必须将 Assignee 指定给自己。
如果某个 Story 过于复杂,或是它需要修改我们的底层框架核心(如 Redux Middlewares)或是共享组件,Story Owner 应该创建更加详细的设计文档
根据自己的时间和所需要交付的东西规划开发时间,同时也要考虑留更多的时间在写测试上面
在你本地的开发机器上先测试,保证基本需求跑通
如果使用 Jira,那么需要记录你的开发时间,并且当代码合并到主干分支后,关闭相应的子任务
基于你的 feature branch 提交代码
确保 Git 提交消息格式满足Git Commit Guidelines。
同时更新你本地的 develop 分支,在提交代码前,执行一次交互式的 rebase,这样可以保证提交历史记录干净并且是线性的。
创建一个 Merge Request,用于 Code Review
CR 的目的是尽量减少代码的 Bugs,而并不会管是谁造成的这个 Bug。同时,我们必须严格遵循 pre-commit CR。
大多数时候,你可能会看见代码合并冲突,请提前解决合并冲突。为了一个更加干净线性的提交历史记录,推荐使用 git rebase
。
无论何时创建 MR 时,请确保Remove source branch when merge request is accepted 和 Squash commits when merge request is accepted 是勾选上的。因为如果勾选上的话,那么接受 MR 后,你的 feature branch 就会被自动删除掉,同时它也会整理该 feature branch 上的提交历史记录。它只会生成一个提交,之后使用项目设置的合并方法来合并这个提交。
指派给 QA 时,尽量添加更多的在用的信息为测试,如项目发布的版本,测试的范围,以及未完成的任务等等。
网站内容许可证:公共领域(public domain)