前端分支规范

开发规模不大，结合比较正式的规范做了一些简化
基本概念

常设分支

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

临时分支

• feature/*** - 任务开发分支
  
• release - 预发布分支
  
• hotfix/*** - 线上热修分支
  

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

正式环境：production
测试环境：testing
开发环境：development
分支说明

master（主分支）

master为主分支，用于部署到正式环境production，一般由release或hotfix分支合并，所有提供给用户使用的正式版本，都在这个主分支上发布，任何情况下不允许直接在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，一旦修复上线，便将其删除。
基本流程

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

命令行示例：

1. # 1 从develop分支创建feature分支
2. git branch -b feature/branch-test develop
4. # 2-1 从master或develop分支（具体条件看上文，这里选择master）创建release分支
5. git branch -b release master
7. # 2-2 切换到release分支，把feature/branch-test分支合并到release分支
8. git checkout release
9. git merge feature/branch-test
11. # 4-1
12. git checkout master
13. git merge release
15. # 4-2 删除feature和release分支（本地）
16. git branch -d feature/branch-test
17. git branch -d release

复制代码

删除分支：

1. # 清除本地remote
2. git remote prune origin
3. # 删除本地分支（-D为强制删除）
4. git branch -d|-D  [branchName]
5. # 删除远程分支
6. git push origin --delete [branchName]

复制代码

其他场景

发布测试环境（release分支）

• 确认要发布的feature 分支上的功能是否开发完毕并提交；
  
• 创建release 分支（发布分支），将所有要发布的分支逐个合并到release分支，有如下情况：
  

• feature分支（可能有多个）
  
• master分支（期间可能有其他release版本更新到了master）
  

• 命名规则（可选）：release-分支创建日期-新特性和待发布版本号
  
• 发布到测试环境，通知测试;
  
• 测试完成后删除本次发布的所有feature分支。
  

修复待发布版本中的Bug（feature分支）

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

• 根据修复后的release分支再次将master合并，打包发布生产环境;
  
• 确认发布成功，并线上验收通过后，将release分支合并到master分支;
  
• 在master分支上创建标签（可选），命名规则：tag-日期-新特性和版本号，版本可根据需要添加，作为发版里程碑标记;
  
• 删除对应release 分支。
  

修复线上Bug（hotfix分支）

• 从master 分支某个tag 上创建一个 hotfix 分支（热修复分支），一般是最新的tag应该和当前生产环境对应；
  
• 开发人员完成Bug 修复，提交hotfix分支到测试环境验收通过;
  
• 再次发布正式环境流程;
  
• 将 hotfix 分支合并到 master 分支;
  
• 在master分支上创建标签（可选），命名规则：tag-日期-新特性和版本号，版本可根据需要添加，作为发版里程碑标记;
  
• 删除 hotfix 分支。
  

来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！