Git使用

分支管理与发布策略

一个仓库只允许一个长期的分支:

master 开发分支

所有的开发人员基于master分支进行开发。

临时分支：

发布分支 - release/{date} (例：release/**20190823**)
线上紧急热修复分支 - hotfix/{date} (例：hotfix/**20190823**)
开发人员临时功能分支 - feature/{feature name} (例：feature/fileupload)

开发模式如下：

获取最新的代码

1
2
3

git checkout master
git fetch
git rebase origin/master

本地开发，然后提交
1
2
git add .
git commit

推送到仓库

1
2
3

git fetch
git rebase origin/master
git push

rebase的时候如果有冲突先解决冲突然后再执行

1 2	git add . git commit

完成后再重复3

注意：

这里只能使用rebase，禁止使用merge

建议：

如果功能较大，一次代码提交不合适，可多次commit最后再一次性push到主仓

如果多人协同一个功能，尽量使用代码原子性、API版本、提前定义接口等方法，把功能拆小后尽快push到主仓，以免影响协作开发的同事

部署

从master拉出一个发布分支

git checkout master
git checkout -b release/20190309
# 推到远端库
git push

在发布分支上进行测试与验证
如果验证发现问题，开发人员提交代码到master并cherry-pick到发布分支，回到2继续
1
git cherry-pick <fix-shal>
完成发布打tag

tag命名规则: release-{date}、hotfix-{release_date}-{seq} (例如：release-20190319、hotfix-20190319-1)

热修复过程

从指定tag checkout 一个hotfix分支（该分支一直存在到下一次release版本发布）。
开发人员在master分支上进行修复，然后cherry pick到hotfix分支。
进行测试与验证，如果发现问题回到2继续
发布hotfix分支，并打tag

注意：

hotfix分支的生命周期应与每一次迭代的生命周期保持一致，上一次发布的热修复会一直在这个分支上进行

commit 规范

1
2
3

<type>: <subject>
<BLANK LINE>
<body>

Type（必要）

描述本次提交的类型。
高频：

feat: 一个新的功能
fix: 修复 Bug
perf: 提高性能的代码
refactor: 代码重构
style: 编码规范、风格上的修改，不影响功能
test: 测试用例修改

低频：

docs: 仅改变项目文档
build: 改变项目构建流程或包依赖
Subject（必要）
用于描述本次 commit 的简要说明
Body（可选）
往往用来描述本次 Commit 的动机、需同步给团队的信息等

参考：https://www.conventionalcommits.org/en/v1.0.0/

配置git提交模板

创建文件 .git_commit_template

1
2
3

<type>: <subject>

<body>

设置为git提交模板

1	git config --global commit.template $HOME/.git_commit_template

API接口文档

为什么我们要使用API接口文档？当前大部分的项目都是前后端分离的开发模式，前端与后台开发必须基于约定进行开发，这样才能并行开发。接口的变化及版本也需要记录并标记下来。对于测试人员也可以提前针对接口编写自动化的测试脚本，可以更早的发现问题。

API接口文档我们选用去哪网前端团队开发的YApi，具体的使用手册请参考这里。
其功能包括：

可视化接口管理
数据mock
自动化接口测试
数据导入（各种，包括swagger、har、postman、json、命令行）
权限管理
支持本地化部署
支持插件
支持二次开发

对于后台开发人员编写API接口文档有以下两种推荐方式：

swagger导入
har导入

Swagger导入，可以在项目中集成Swagger，并使用Swagger maven plugin在每次打包时生成swagger的json格式api，可直接导入YApi。
HAR导入，har是HTTP Archive format的简称，我们写好代码，在开发自测调试时可以在chrome中访问我们的接口，chrome可以自动记录并将所有的请求保存为har格式的文件并导入YApi，如下图所示。

代码评审 - CodeReview

代码评审在不管任何项目或产品的开发过程中都是不可或缺的一步。一般项目都不会由一个人开发完成，都是由团队中的多人共同合作完成，但团队中的人员级别不一素质不同，因此代码评审可以帮助团队生产出的代码质量更均一，初级的开发人员可以更快速的提升自己能力，一些bug可以尽早发现。除此外还为什么我们强调代码评审是一个不可或缺的一步？如果不这样做为有什么问题？

没有人可以完全了解一个项目所包含的所有代码，因为这些代码是由不同的人编写的。
项目中的某些代码都只有作者自己才能看到。
质量差的代码很可能会长期存在。
没有人应对他人的代码负责，甚至不为自己的代码负责。
团队成员发现很难获得经验并提高编码技能。
糟糕的代码在测试阶段将会引起许多小问题。
糟糕的代码会在开发人员修复bug时造成很大的困难（改出更多的bug）。
当新开发人员加入项目时，他们的代码可能是风险最高的代码。
对三个月前的代码进行重构将会非常复杂。

因此我们需要通过代码评审来解决上面这些问题。

对于一个新的功能或业务的开发（已有功能的修改和bugfix不算在内，除非这个改动影响比较大），其代码入库前需要进行代码评审，我们这里采用基于GitLab的Merge Request进行Code Review，步骤如下：