分支管理规范

前端规范

前言

软件项目迭代，版本管理系统必不可少。基于版本管理，连接项目启动，开发，测试，部署，迭代流程，打造高效的前端开发 workflow，以提升效率。分支管理则为重中之重，良好的分支管理规范，避免项目分支混乱。

客观条件

中小企业，基础设施并不完善，无法完全沿用 github，gitlab 风格。

当前无规范迭代状态，暴露问题如下：

• 开发版本、测试版本、生产版本代码边界不清
• 已发布版本代码回溯困难
• 无代码评审
• 开发与开发协作困难，代码合并产生大量冲突
• 开发与测试协作困难,重置测试环境需要开发深度介入

主要业务面向企业，对稳定性的要求远大于快速迭代的需求，业务开发满足以下条件：

• 项目迭代周期较为平缓；
• 新增特性串行开发；
• 提测顺序与上线顺序匹配；

分支说明

分支管理的核心在于提升开发效率，分支派生需要解决从何处来，实现什么功能，到何处去的问题。主要包含以下几类分支：

• master
• hotfix
• feature
• technique

master 作为主分支。分支仅包含测试通过的代码，用于生产环境上线。所有代码通过分支合并而来，禁止直接在主分支上开发[1]。

hotfix 作为紧急修复分支。若生产出现严重问题，直接从 master 分支切出，bug 修复之后，合并回 master 分支，保证代码的连续性，避免问题修复与迭代出现重大冲突，延误时机。

technique 作为技术升级分支，feature 作为业务开发分支，特别约定，非紧急 bug 反馈，统一纳入 technique 范畴，统一发布计划。

master 与 hotfix 分支簇功能非常明确，开发分支与测试分支具体环境下不尽相同，具体环境下具体说明。

分支管理

使用 github flow 方式，开发模式如下：

1. 开发人员接受 issue，从 master 分支切出开发分支，命名风格统一为 分支簇/分支名称，分支簇名称依据 issue 类型选择，分支名称多个单词使用 - 连接。
2. 开发分支上进行开发，并推送到仓库对应分支；
3. 自测完毕，向 master 分支发起 pull request[2]，并连接对应 issue；
4. 持续集成部署开发分支到 uat 环境，自测或测试人员介入，bug 修复全部在开发分支上进行[3]；
5. 测试完毕后，其他成员 code review 完毕[4]，合并到主干分支，生产上线[5]；

若生产出现严重问题，直接从 master 分支切出 hotfix 分支，新建 issue 描述，修复完毕后，向 master 分支发起 pull request，并连接对应 issue。部署后，删除 hotfix 分支。

命令行描述

# 开辟特性分支
git checkout -b feature/staff-manage master;
git checkout -b feature/holiday master;
# 独立代码演进
git add something;
git commit -m "something";
git push origin;
# `code review` 合并之前，要求使用 `git rebase` 简化提交历史，选择`gitlab` 合并后删除原始分支
git rebase master;

版本号变更

发布版本包含多个开发分支

版本号包含双层含义，源码中版本号记录变更，代码仓库中 版本 tag，建议完成 pull request 之后，owner 拉取代码，变更版本后进行发布。

联系作者

Email: hjj491229492@hotmail.com