前端分支规范

时间:2023-02-24 17:08:54

开发规模不大,结合比较正式的规范做了一些简化

基本概念

常设分支

  • master - 主分支,用于正式发布
  • develop - 开发分支,用于创建新开发feature分支

临时分支

  • feature/*** - 任务开发分支

  • release - 预发布分支

  • hotfix/*** - 线上热修分支

这三种分支都属于临时性需要,使用完以后,应该删除,使得代码库的常设分支始终只有Master和Develop。

环境

正式环境:production

测试环境:testing

开发环境:development

分支说明

master(主分支)

master为主分支,用于部署到正式环境production,一般由releasehotfix分支合并,所有提供给用户使用的正式版本,都在这个主分支上发布,任何情况下不允许直接在master分支上修改代码。

develop(开发)

develop为开发分支,始终保持最新完成以及 bug 修复后的代码,可根据需求大小程度(工时是否小于一天)确定是由 feature 分支合并,还是直接在上面开发。

持续集成、最新隔夜版本的生成等都是基于这个分支。

release(预上线分支、预发布分支)

release为预上线分支,用于部署到测试环境testing,发布正式版本之前(即合并到Master分支之前),我们可能需要有一个预发布的版本进行测试。从master或develop拉取,测试完成merge回master和develop

如果 存在 未测试完毕的需求,就基于master创建。

如果 不存在 未测试完毕的需求,就基于develop创建。

不建议直接在release分支上直接修改代码。

feature 分支

feature为需求开发分支,从develop拉取,开发feature完成,merge回develop,一旦该需求上线,便将其删除。

hotfix(线上热修分支)

hotfix 为紧急修复分支,从master拉取,修复并测试完成merge回master和develop,一旦修复上线,便将其删除。

基本流程

  1. 每开发一个新功能,创建一个feature分支,多人在此分支上开发;
  2. 提测时,将master分支和需要提测的分支汇总到一个release分支,发布测试环境;
  3. 发现bug时,在feature分支上debug后,再次回到2;
  4. 发布生产环境后,将release分支合并到master分支,删除release分支。

命令行示例:

# 1 从develop分支创建feature分支
git branch -b feature/branch-test develop

# 2-1 从master或develop分支(具体条件看上文,这里选择master)创建release分支
git branch -b release master

# 2-2 切换到release分支,把feature/branch-test分支合并到release分支
git checkout release
git merge feature/branch-test

# 4-1
git checkout master
git merge release

# 4-2 删除feature和release分支(本地)
git branch -d feature/branch-test
git branch -d release

删除分支:

# 清除本地remote
git remote prune origin
# 删除本地分支(-D为强制删除)
git branch -d|-D  [branchName]
# 删除远程分支
git push origin --delete [branchName]

其他场景

发布测试环境(release分支)

  1. 确认要发布的feature 分支上的功能是否开发完毕并提交;

  2. 创建release 分支(发布分支),将所有要发布的分支逐个合并到release分支,有如下情况:

  • feature分支(可能有多个)

  • master分支(期间可能有其他release版本更新到了master)

  1. 命名规则(可选):release-分支创建日期-新特性和待发布版本号

  2. 发布到测试环境,通知测试;

  3. 测试完成后删除本次发布的所有feature分支。

修复待发布版本中的Bug(feature分支)

如果发现bug,开发人员在 feature 分支上修复测试人员提交给自己的bug,修复完成后,合并到 release 分支,发布测试环境。

发布正式环境

  1. 根据修复后的release分支再次将master合并,打包发布生产环境;

  2. 确认发布成功,并线上验收通过后,将release分支合并到master分支;

  3. 在master分支上创建标签(可选),命名规则:tag-日期-新特性和版本号,版本可根据需要添加,作为发版里程碑标记;

  4. 删除对应release 分支。

修复线上Bug(hotfix分支)

  1. 从master 分支某个tag 上创建一个 hotfix 分支(热修复分支),一般是最新的tag应该和当前生产环境对应;

  2. 开发人员完成Bug 修复,提交hotfix分支到测试环境验收通过;

  3. 再次发布正式环境流程;

  4. 将 hotfix 分支合并到 master 分支;

  5. 在master分支上创建标签(可选),命名规则:tag-日期-新特性和版本号,版本可根据需要添加,作为发版里程碑标记;

  6. 删除 hotfix 分支。