相关规范 + 开发

git branch & code review(结合企业级流程)

开发人员：

产品：

后端：

前端：

测试：

运维：

大数据：

ui：

美工：

总人力：人次

周三：产品需求评审

周五：各同学需要根据需求评审确定需求给出需要交付的东西

一、里程碑展示

项目启动会会建个群，有项目文档

项目启动会 --> PRD评审(产需求文档，原型图评审) & UI评审(具体到某种动画交互不懂的要问清楚) --> 后端接口字段评审 --> 测试用例评审(p0最高优先级，p1,p2) --> 前后端联调 --> 第一轮提测（test环境） --> 第二轮提测（pre环境）

PRD评审&UI评审 后，有任务分解会（开发团队） --> 站立会，周风险会 --> 复盘回忆 --> 迭代

二、相关规范 + 开发

1.分支命名规范

1.FEATURE 分支命名：feature/项目代号.项目周期_name

• 例如：feature/hytrip.1.0.0_rsy
  2.给测试的，最后都会合并到release分支测试：RELEASE 分支命名：release/项目代号.项目周期 -例如：release/hytrip.1.0.0
  3.HOTFIX 分支命名：hotfix/项目代号.项目周期_name
  4.上线都会打Tag，TAG命名：V-项目代号.项目周期 -例如：V-hytrip.1.0.0 V代表版本号的意思，前面的V是固定的

（一）项目启动阶段

1.在master分支上 git checkout -b release/hytrip.1.0.0

• 快速创建并切换到release分支上
  2.git push
• 终端有可能会提示 git push --set-upstream origin release/hytrip.1.0.0

1.1初始化git仓库

1.克隆远程仓库
git clone <仓库地址>

2.提交并推送初始版本（这一步一般组长会做好）
# 提交本地修改：
	git add .
	git commit -m "提交日志"
# 推送 master 分支：
	git push origin master
	
3.创建开发分支 (一般都会给配好)
# 从 master 分支上创建 develop 分支：
	git checkout -b develop master
# 推送 develop 分支：
	git push origin develop

（二）需求开发阶段（组长 + 组员）

1.从 master 分支 checkout 一个 feature 分支
	- 代码步骤： git checkout -b feature/hytrip.1.0.0_rsy

2.进行功能模块开发（码代码中）

3.功能模块开发完成后：
	- 代码步骤：
		git add .                跟踪新文件，添加到暂存状态 
		git status -s            查看状态 
		git diff                 不加参数即默认比较工作区与暂存区,add . 之后 diff  就看不到了
		git commit -a -m "feat(*):xxx功能" 添加-a是跳过暂存区，自动把所有已跟踪过的文件暂存起来一起提交，从而跳过git add 步骤
		例如：git commit -a -m "feat(views/test2): 添加test2功能模块"
		git push

（三）第一轮提测test的前一天完成以下任务

第一轮提测test（组员）

找到提交历史，点击，然后点合并请求 --> 创建合并请求 --> 最上面从 xx 到 main 更改分支，提测时候要改成到 release
分支 -->填写标题，描述（1.完成功能1;2.完成功能2…;3.完成接口测试…) --> 指派人 --> 审核者 -->
合并选项（先不用选） --> changes 提交之前看下自己的改动对不对 --> 没问题后创建合并请求 create -->
然后告诉组长提交上去了

第一轮提测test（组长）

1.确定所有的同学功能都已经开发完毕，并且他们各自的feature分支已经 merge 到 release/hytrip.1.0.0分支，各自分支向release测试分支合并的过程叫 code review

2.通知（邮件/群通知）测试团队，开始用 jinkins 打包，分支选择 release/hytrip.1.0.0 进行发布，然后测试。

组长：在组员提交完成后，合并请求后面会显示数字 --> 点进去 --> 点变更 --> 查看有无问题，评审意见 --》 启动评审 -->
提交评审 --> 返回后，显示的最右边会有一个信息框提示 组员：组员解决问题后重新回复已解决该问题 --> 提交评审 组长：批准 -->
点击进行合并 -->注意：不能勾选删除源分支 然后就提交到 release 分支上了

（四）BUG fixed

1.在自己的原先 feature 分支上进行 bug fix,保证 bus 每日清。修好看看一下，提交合并
	修改bug
	git diff 查看一下对比
	git commit -a -m "fix(*): xxx bug fixed"  提交
	git push
	然后再重新发起合并请求，合并到release分支
2.和组长沟通，每天预留半个小时来进行 code reveiw 操作（见第一轮提测（组员）上面整个流程步骤）

BUG fixed中（组长）

1.见上图（第一轮提测（组长）全流程步骤。

（五）第二轮提测（预发环境PRE）（组长）

开发只要保证自己的bug日清就可以了。

1.确定所有的同学功能都已经开发完毕，并且他们各自的feature分支已经 merge 到 release/hytrip.1.0.0分支，各自分支向release测试分支合并的过程叫 code review。
2.通知（邮件/群通知）测试团队，开始用 jinkins 打包，分支选择 release/hytrip.1.0.0 进行发布，然后测试。

（六）项目上线（组长）

1.把 release/hytrip.1.0.0 merge 到 master 分支
2.从 master 分支上打 tag 名称

• 仓库里有个标签 --> 新建标签 V-hytrip.1.0.0 --> create from master --> message 例如：1.完成了xxx功能。 --> 创建标签
  3.（群通知/邮件）形式通知（测试主管/项目经理）,项目名是xxx,tag名是xxx，完成了xxx功能，包的 tag 名称已经打好，让他们安排包的发布操作。

三、code review 流程

Code Review 中文应该译作“代码审查”或是“代码评审”，这是一个流程，当开发人员写好代码后，需要让别人来review一下他的代码，这是一种有效发现BUG的方法。由此，我们可以审查代码的风格、逻辑、思路……，找出问题，以及改进代码。因为这是代码刚刚出炉的时候，所以，这也是代码重构，代码调整，代码修改的最佳时候。所以，Code Review是编码实现中最最重要的一个环节。

code review步骤

1.了解改动背景

• 首先你得知道你要看的代码实现了什么样的功能，是在什么样的背景下去做的，清楚前因后果之后，你才能知道这个代码大概应该怎么去写，你才能更好的去Review别人的代码、去发现别人的问题。
  2.纵观全局
• 了解背景后，你脑海中就会有一个大概的编码思路，也有个流程主线。
• 如果思路相同，就顺着你们共同的思路去帮忙Review整个流程是否正确。
• 如果思路不同，你就得看代码去了解写作者的思路，然后确认是谁的思路有问题，或者是谁的思路更好，然后同写作者一起将这个流程优化到更优。
  3.逐层细化
• 确定完整个流程之后，就可以逐步深入到代码细节中了，细节可以Review的地方就很多了。 关注点
  1.功能性：实现的功能是否和预期一样，是否实现了所有必须的功能？
  2.复杂性：是否过于复杂？是否易维护？
  3.代码风格：是否符合团队编码规范？
  4.文档&注释
  5.代码亮点

选什么工具辅助做CODE REVIEW？

现在很多源代码管理工具都自带Code Review工具，典型的像Github、Gitlab、微软的Azure DevOps，尤其是像Gitlab，还可以自己在本地搭建环境，根据自己的需要灵活配置。

工具	方式
github	pull request
gitlab	merge request
gitee	merge request

先设计再编码

建议在做一个新功能之前，写一个简单的设计文档，表达清楚自己的设计思路，找资深的先帮你做一下设计的审查，发现设计上的问题。设计上没问题了，再着手开发，那么到Review的时候，相对问题就会少很多。

配合什么样的开发流程比较好？

像Github Flow这样基于分支开发的流程是特别适合搭配Code Review的。其实不管什么样的开发流程，关键点在于代码合并到master（主干）之前，要先做Code Review。

提交code review前先做好自审

提前自己处理掉一些低级错误，可以先借助一些工具完成一些简单的检查。例如我们团队会借助checkstyle、spotbug、sonar、pmd等工具完成代码风格和一些潜在bug的检查。然后自己做好功能的自测，尽可能先消灭一部分bug，为CodeReview减少一些负担。

写清楚变更描述

在变更描述中将这些信息描述清楚，包括但不仅限于改动背景、改动点、流程、具体设计…… 一句话概括就是**「好的变更描述应该说清楚这次是做了什么变更，以及为什么要这么做」**。

CodeReview流程应该尽早提交

日常情况下，还是建议早点提交CodeReview，并留出一定的时间来做修改，尽可能不要让这个流程变的匆忙。大部分公司的实践都是在进入测试流程的时候同时进入CodeReview流程。

每日站会

会议规定：

每个工作日早上9点25准时开始
时长不超过15分钟
所有团队成员需要自觉按时到场，按时召开
同一时间只能有一个人发言，只说相关的问题，任何跑题或扩展讨论，请在会议结束后进行
团队成员最好提前准备发言内容，别的成员发言时，注意倾听

会议内容：

我昨天完成了什么？（你昨天做了什么来改变世界）
我今天要做什么？（你今天准备怎么做）
什么障碍拖延了我的进度？（你准备怎么突破任何不幸挡了你路的困难）

会议目的

项目进度定期同步
对目标有同样的理解
协调工作
分享问题和改进
识别为一个团队