主要是分享一下自己这些年开发下来,觉得比较好的一些团队开发经验,包括git&代码规范。
git规范推荐
- master分支 ,一直保持最新可发布的代码分支。
- release分支,每次迭代的发布分支,已发布日期命名,比如我们的app版本是0101,则是起一个release_0101,后续我们需要再0101发布的需求都合并到该分支。在该分支发布之后,我们就打一个tag,将该代码合并到master中,然后再三个月之后再删除该分支,便于查找。
- 开发人员自己的需求的分支以
feature/bugfix
名字开头+自己的名字
+需求描述
作为分支名称,比如叫feature/jackey/user_info
。 - feature同步release分支代码,必须使用
rebase
命令。固定人员CR并合并feature到release的代码的时候,使用merge
命令 - feature分支在开发的时候可以有多次commit,但是在测试通过验收完成需要合并到release的时候,需要使用
rebase -i
把所有的commit合并为一个,commit msg可以较为详细,然后删除该分支的origin分支,重新push上去,再提交MR。这样就不会有很多无用的commit,别人也能直接通过你的一次commit看到你的本次代码改动,方便CR。
关于如何使用git的相关命令,这里就不赘述了。
代码规范
主要是有两块
- 检测代码的命名,格式,规范性(比如if的括号),代码的复杂度(比如过长的方法),以及一些无用字段的检测
- 对于大家使用快捷键的时候的格式化,每个人的电脑可能都会有所不同。他会导致合并mr的时候出现一些无用冲突,也会有一些无用的代码提交。
由于我们主要使用的都是kotlin,所以我们就引入了detekt
工具来做的校验(即第一点),然后统一使用java11,引入AS插件google-java-format & ktfm
,引入 spotless
来做提交的检测,做一个格式化时候的约束(即第二点)。
下面是一段可用的sh命名,可以用于配置git commit
的时候作为git hook
去进行格式检测。
1 | #!/bin/sh |
工具
- 比如内存泄露检测的
leakcanary
- 滴滴的哆啦A梦工具箱,肥肠好用
- 通知栏展示http请求的
chuck