相关规范 + 开发

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分钟
所有团队成员需要自觉按时到场,按时召开
同一时间只能有一个人发言,只说相关的问题,任何跑题或扩展讨论,请在会议结束后进行
团队成员最好提前准备发言内容,别的成员发言时,注意倾听

会议内容:

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

会议目的

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

你可能感兴趣的:(codereview,git,git)