刚做完一个项目并且艰难得上线，对整个项目流程和gitLab规范 有了一些心得，给新来的同学普及一下。
最先产品会写一篇需求文档，咱们要先看需求文档对项目有一个大致了解，然后产品喊后端、ui、前端 一起在讨论-一下项目，对项目有一个明确的认知，如果讨论过程中 有咱们没有做过功能，咱们需要调研。 ui画完图 咱们先看图 想想一下项目的整个交互流程 感觉哪地方逻辑不对 可以和ui、产品一起商量，商量的时候记得叫上后端，别你们商量好了有改动 人家后端还不知道怎么回事那。 如果一些布局 你看着难受别扭，可以和ui商量 但是以ui为主，毕竟人家是 干这个的，还有刚来咱们公司 肯定会遇到没psd图 你没法量 但是还需要符合规范的情况，三种方式 你要求ui出psd图 、 还有就是 自己看《web端交互规范》和让ui 在图上标识距离像素。一般都是第三种，但是 由于咱们有组件库 通常情况下 都是不用测量距离。
对项目有明确认知 就可以开始画类图，类关系用什么标识连接点开这个链接有详细说明 https://design-patterns.readthedocs.io/zh_CN/latest/read_uml.html ，不会画 或者 类关系不明白的 可以问各自师傅，类图是重中之重 真正开始写代码的时候 是要跟根据类图来做的。mock在这个时候 也可以与后台制定了。
然后ui图出完之后，咱们就可以开始画交互时序图了，交互时序图要体现出 用户的操作流程和交互效果，交互时序图画完要给ui看一下，哪地方的交互有问题 ui会和你说的。
图画完让师傅或者组长检查一下，然后就可以开始预演了，预演就是 你拿着这两个图，给团队其他成员 去讲解，尤其是 交互时序图 需要和团队成员达成思想一致，才算预演成功。预演通过后，需要在gitLab上自己所在项目拆分issue，
当然项目中的第一个issue 是标题：开发预演 描述：如：考试项目v1.0里程碑，预演结果--包括交互时序图和组件的类图，评论里面 发送 交互时序图和类图，开发预演issue通过了，并且组长评论了就可以关闭开发预演issue了。
创建某个issue时 需要在该issue下 评论预估时间如 /estimate 2h， h时小时、d是天数。
完成issue时 需要评论实际时间 /spend 2h 如果实际时间超出预估时间，要评论超出时长原因。
完成一个issue的流程 ：
创建issue 如上图----评论预估完成该issue时间----准备完成某issue更改标记、选择截至日期----代码完成时push到该issue的分支上-----在该issue上评论实际时间--如果超时在评论超时原因--
我们开始开发功能是在dev上创建分支，功能分支 就是开发项目里面还没有的新功能的分支，以dev-feat开头。功能开发完之后确定没有问题，合并到dev，如果合并到dev之后发现有问题要修复，在dev分支上建bug修复分支，以dev-fix开头，修复完之后合并回dev，功能全部开发完毕。
完成所有issue 准备提测，提测之前需要进行代码评审，创建代码评审issue 如果有被审查出来的问题 描述里面把每个问题都写上，每个问题再单独创建一个issue,如果没有问题，找这次评审的负责人 进行评论通过，然后将dev合并到release，由测试组同事完成合并。
dev合并release之前 需要配置好webpack，向运维要你项目的测试地址（域名），向后端要后端的服务测试地址。
合并到release 并且项目 能运行了，就算是提测成功，在测试期间 如果测试给你找到bug 他会创建issue 并把issue 指派给你，如果你发现是后端问题 你在和测试说 让他指派给后端，领到issue后评论issue预估时间、更改结束时间，完成后需要评论实际完成时间，分支名字根据下图来创建：
在测试环境发现的问题，在release分支上创建分支，以fix开头，修复完合并回release 指派给测试，测试合并后，然后关闭该issue。
测试完毕后，测试会创建预上线通知，咱们前端会在预上线issue里面检查并勾选检查项，然后测试把relase合并到master指派给产品，产品合并后关闭上线通知issue，在线上如果找到bug 产品会创建RC里程碑，线上bug issue指向RC里程碑，在master分支上创建分支，以hotfix开头，修复完合并回master指派给运维，运维合并后，然后关闭该issue。
项目线上没有问题后，master合并到dev，项目负责人自己提合并请求，自己完成合并，然后将dev合并到release ，测试组同事完成合并。最后会开项目总结会要记住 开会的时候总结的几点 ，最后会写项目总结 写到项目维基里。
