一、分支管理
dev 开发分支
test 测试分支
master 主分支
feature/xx-xx 临时/开发分支
hostfix 临时/热修复分支
一般来说 dev、test、master 分支是三个比较基础的分支, 每个项目都应该有.
在三个分支基础上, feature分支可以作为新功能开发的分支, 这是一个临时的分支, 每当有一个新的需求的时候, 我们需要从主分支上创建一个临时的 feature 分支, 创建分支时需要添加分支的说明加一些姓名日期之类的(可选)作为分支的标识, 然后就可以在这个分支上进行新需求的开发, 这样可以保证在我们的新功能没有开发完成之前并不影响到主分支上的内容, 直到我们将这个功能开发完成准备提测的时候, 将这个分支的修改合并到 dev 分支上, 然后就可以让测试去发布测试.
当我们有一个紧急的需求需要修改后发布到生产环境或用户验收环境(UAT)时, 我们首先在master分支上拉取最新的代码, 创建一个release分支, 然后将 feature 分支合并到 release 分支上, 使用 feature 发布. 这样做的好处时我们虽然发布了合并的内容, 但是并没有改动 master 分支的代码, 如果发布上去的内容存在问题, 我们可以快速的切换到master分支上重新发布, 即版本回退.
hostfix 分支的操作逻辑与 feature 分支基本相同, 不同的是 hostfix 主要负责代码的修复.
graph TD
开发新需求
--> 从master分支新建feature/xxx分支
--> 在功能分支上开发,提交内容*n次
--> 开发环境更新:将代码合并到dev分支
--> 生产环境更新:创建发布分支,把代码合并到发布分支
--> 发布成功后将代码合并到master分支
// ************************************ 开发新功能
// 创建分支
git checkout master
git checkout -b feature/xxx
// 提交代码到远端
git push origin feature/xxx
// ************************************ 发布到开发环境
// 切换到dev分支并更新
git checkout develop
git pull origin develop
// 合并代码到dev分支
git merge feature/xxx(有冲突解决冲突)
git push origin develop
// ************************************ 发布到正式环境
// 创建发布分支
git checkout master(切换到master分支)
git pull origin master（拉取master最新代码）
git checkout -b release-feturexxx（创建并切换到新分支上，可以分成两步：git branch release-feturexxx,git checkout release-feturexxx）
// 合并到发布分支并提交
git checkout release-feturexxx
git merge feturexxx
git push origin release-feturexxx
// 发布成功后合并代码到master
git checkout master
关于环境
| 环境 | 分支 | 说明 |
|---|---|---|
| 开发环境(DEV) | dev | 开发人员使用的环境, 可以用于开发人员自测，版本极度不稳定 |
| 测试环境(TEST) | test | 外部用户无法访问，专门给测试人员使用的，版本相对稳定 |
| 系统集成测试(SIT) | test | 开发人员自己测试流程是否走通, 也可以叫内侧环境 |
| 性能评估测试(PET) | test | 用于测试软件性能, 承载量, 也可以叫做压测环境 |
| 用户验收环境(UAT) | test | 用于生产环境下的软件测试者测试使用, 一般是项目验收的测试人员使用 |
| 功能验收环境(FAT) | test | 用于软件测试者测试使用 |
| 灰度环境(PRE) | master | 灰度测试环境就是生产环境，生产数据，所影响的也是生产环境，只是范围比测试环境更广，更真实。可以外部访问, 不过机器配置可能相对较低, 其实就是小范围的生产环境, 类似于游戏内测(公测)。 |
| 生产环境(PRD) | master | 正式的线上环境 |
这里面比较基础的是 DEV、TEST、PRE、PRD 四个环境, 其余环境则是为了更好的划分而产生的特定的测试环境.
部分开发者可能不太明白为什么要这么划分成四个环境, 甚至有部分开发者认为只要有 DEV、PRD 两个环境就足够了, 这个在项目开发期或许是没有问题的, 同时也能更快的迭代, 但是在上线之后如果遇到BUG, 且此时DEV上还有没有开发完成的代码, 就很难处理.
二、提交规范
先更新!!!先更新!!!先更新!!! 重要的事情说三遍! 提交代码前必须先更新代码, 处理好冲突!
格式:
[type]:[scope][subject]
[body]
示例:
fix:[用户管理]修改用户报错
修复编辑用户时初始化用户性别报错
// @param type
必须 说明本次修改类型
feat：新功能（feature）
fix：修补bug
docs：文档（documentation）
style： 格式（不影响代码运行的变动）
refactor：重构（即不是新增功能，也不是修改bug的代码变动）
test：增加测试
chore：构建过程或辅助工具的变动
// @param scope
可选 说明本次修改范围
例如 视图层、模型层、控制层, 或者 某页面、某组件、某模块等
// @param subject
必须 说明本次修改内容、使用第一人称现在时以动词开头
// @param body
可选 具体修改内容
三、代码评审(Code Review)
偷懒, 先放一个别的同学写的链接🙈🙈🙈前端代码评审通常注意些什么
