-
master
分支master
为主分支,也是用于部署生产环境的分支,确保master
分支稳定性
master
分支一般由dev
以及hotfix
分支合并,任何时间都不能直接修改代码 -
dev
分支dev
为开发分支,始终保持最新完成以及 bug 修复后的代码
一般开发的新功能时,feature
分支都是基于dev
分支下创建的
-
feature
分支开发新功能时,以
dev
为基础创建feature
分支
分支命名:feature/
开头的为特性分支, 命名规则:feature/user-module
、feature/cart-module
-
hotfix
分支分支命名:
hotfix/
开头的为修复分支,它的命名规则与feature
分支类似
线上出现紧急问题时,需要及时修复,以master
分支为基线,创建hotfix
分支,修复完成后,需要合并到master
分支和dev
分支 -
release
分支release
为预上线分支,发布提测阶段,会以release
分支代码为基准提测
当有一组
feature
开发完成,首先会合并到dev
分支,进入提测时,会创建release
分支。 如果测试过程中若存在bug需要修复,则直接由开发者在release
分支修复并提交。 当测试完成之后,合并release
分支到master
和dev
分支,此时master
为最新代码,用作上线。
采用 semver 语义化版本 标准
- 版本格式:主版本号.次版本号.修订号
- 主版本号:当你做了不兼容的 API 修改,
- 次版本号:当你做了向下兼容的功能性新增,
- 修订号:当你做了向下兼容的问题修正。
推荐可以使用 standard-version 进行版本管理,如本项目在 package.json
中添加该依赖并且加入了相关的命令(这个可以配合 CI 流程进行)
"release:major": "standard-version -r major -n", // 主版本更改
"release:minor": "standard-version -r minor -n", // 次版本更改
"release:patch": "standard-version -r patch -n", // 修复版本更改
"prerelease:alpha": "standard-version -p alpha -n", // alpha 版本
"prerelease:beta": "standard-version -p beta -n" // beta 版本
-
增加新功能
(dev)$: git checkout -b feature/xxx # 从 dev 建立特性分支 (feature/xxx)$: blabla # 开发 (feature/xxx)$: git add xxx # 添加文件的时候注意一定不要将不相关的文件都带到远程仓库 (feature/xxx)$: git commit -m 'feat: 功能说明' (dev)$: git merge feature/xxx --no-ff # 把特性分支合并到 dev
-
修复紧急 bug
(master)$: git checkout -b hotfix/xxx # 从master建立 hotfix 分支 (hotfix/xxx)$: blabla # 开发 (hotfix/xxx)$: git add xxx # 添加文件的时候注意一定不要将不相关的文件都带到远程仓库 (hotfix/xxx)$: git commit -m 'commit comment' (master)$: git merge hotfix/xxx --no-ff # 把 hotfix 分支合并到 master,并上线到生产环境 (dev)$: git merge hotfix/xxx --no-ff # 把 hotfix 分支合并到 dev,同步代码
-
测试|预发布环境
(release)$: git merge dev --no-ff # 把dev分支合并到release,然后在测试环境拉取并测试
-
生成环境代码
(master)$: git merge release --no-ff # 把release测试好的代码合并到master,运维人员操作 # 打 tag 标签:这个根据实际情况来进行 alpha、patch、minor、major 版本发布 (master)$: npm run prerelease:alpha|release:patch|release:minor|release:major