¶ 概要
本规范旨在统一公司代码仓库管理流程，提高协作效率，保障代码质量和可维护性。包含以下核心内容：
- 仓库规范：创建与命名规则
- 分支模型: git 分支管理
- 代码提交规范：标准化提交格式与审查流程
- 发布维护规范：版本管理与生产部署标准
¶ 仓库规范
规范第一条: 公司任何代码不允许上传至任何三方开源平台(如:GitHub、Gitee、码云等)
所有公司项目都涉及商业合作和法律问题。因此，所有参与项目开发的人员都有责任和义务保护公司和甲方客户的商业生产资料。如果由于员工个人原因导致源代码泄露造成客户损失的，客户和公司都有权依法追究法律责任。员工将自行承担由此造成的所有损失。
¶ 一、仓库创建规范
-
公司交付项目必须通过员工平台-项目git创建功能进行项目创建
-
若有项目存在无法适用情况。则由部门经理进行项目创建工作。并提报至架构部。架构部人员负责收集处理。并将项目模板提供至员工平台
-
部门经理负责项目创建核查。质检部以及架构部不定期进行检查。
-
必须符合项目命名规范。
-
仓库可见性必须为私有。(员工平台创建默认为私有)
-
仓库描述补全。（楼兰微信小程序，楼兰后台）。
¶ 二、仓库命名规范
项目命名规范。用于约束git项目命名规则。有助于项目管理与追溯。其命名规则如下
LX{no}-{name}-{flag}-[option]。
其中:
-
no: 为项目编号。员工平台项目立项后生成的项目编号。通过员工平台创建的git会自动携带。无需开发人员填写。如果你是手动创建。规则为LX{立项单号} -
name: 项目名称的中文拼音。例如：标准商城(biaozhunshangcheng)。禁止英文/缩写 -
flag: 为项目标识。用于区分不同的项目类型。具体类型如下后端:
java: JAVA项目php: PHP项目nodejs: Nodejs项目
前端:
taro或uni（默认）跨端项目。最通用命名方式，表示包含H5、各类小程序以及后台管理项目。appapp项目。包含React Native、Uniapp、原生开发等。纯原生可以通过option做区分weapp微信小程序项目。包含后管系统。如果你想精确命中项目类型。这个名称是个不错的选择。backend纯后台管理项目pcweb pc 端mobile（废弃）web 手机端（公众号也包括在内）fronted前端项目。此种命名风格比较宽泛。适用于使用Taro开发框架的项目。请注意。不到万不得已。不要使用这种命名方式。
如有遗漏。提出补充
option: 可选。有些时候项目通过上述仍无法满足项目表述。比如java项目有多个服务端、纯原生区分安卓与IOS。这时。你可以追加option字段做进一步的区分。
¶ 示例
举几个栗子:
// 普通
LX001519-shangcheng-java 商城Java项目
LX001519-shangcheng-taro 商城跨端项目。包含微信小程序、H5、后台管理系统
// 多个项目 带 opion字段
LX001519-shangcheng-java-merchant 商城Java项目商家平台
LX001519-shangcheng-java-admin 商城Java项目管理平台
LX001519-shangcheng-app-android 商城Android APP
LX001519-shangcheng-app-ios 商城IOS APP
¶ 分支模型:
本司分支管理规范采用 阿里云云效分支管理规范。兼顾实施性/便捷性/流水线集成性。
¶ 分支规范
总体来说，几个原则：
-
master代表最新发布版本: 不要直接在master分支开发修改代码
-
feature分支上开发：基于 master 分支最新版本创建 feature 分支。然后在 feature 分支上开发、测试，直到这个 feature 功能完成
-
release 分支测试/集成: release 分支用于集成和发布。基于 master 分支最新版本创建一条 release 分支，然后把想要集成的各条feature分支合并到这条release分支，进行部署和测试工作。
使用者不要直接在上面改代码，代码修改请总是在 feature 分支完成。 -
hotfix分支用于线上问题紧急修复: 当生产环境出现问题。根据实际情况有两种处理方式。回滚发布或者是紧急修复。如果需要紧急修复。则从master分支迁出hotfix分支进行修复。测试验证后合并进入master分支
具体细节或者需要接入云效流水线。参考阿里云云效分支管理规范 了解详细讲述
| 分支类型 | 来源 | 合并目标 | 生命周期 |
|---|---|---|---|
| master | release/hotfix | - | 永久 |
| feature/* | master | release/* | 功能开发周期 |
| release/* | feature | master | 版本发布周期 |
| hotfix/* | master | master | 紧急修复周期 |
¶ 代码提交规范
代码提交规范 参照 约定式提交
¶ 目的
-
统一团队 Git commit 日志标准，便于后续代码 review，版本发布以及日志自动化生成等等。
-
统一团队的 Git 工作流，包括分支使用、tag 规范、issue 等
¶ 提交格式
<type>([optional scope]): <subject>
<BLANK LINE>
[optional body]
<BLANK LINE>
[optional footer]
示例：
# 简单格式
feat(login): 增加短信验证码登录功能
# 完整格式
fix(payment): 修复支付宝回调处理异常
BREAKING CHANGE: 支付接口签名算法升级为SHA256
Closes #123
type代表某次提交的类型，比如是修复一个bug还是增加一个新的feature。所有的 type 类型如下：
- feat: 新增 feature
- fix: 修复 bug
- docs: 仅仅修改了文档，比如 README, CHANGELOG, CONTRIBUTE等等
- style: 仅仅修改了空格、格式缩进、逗号等等，不改变代码逻辑
- refactor: 代码重构，没有加新功能或者修复 bug
- perf: 优化相关，比如提升性能、体验
- test: 测试用例，包括单元测试、集成测试等
- chore: 改变构建流程、或者增加依赖库、工具等
- revert: 回滚到上一个版本
scope: 代表提交作用域。用于辅助提示本次提交影响范围。比如 user用户模块/ login 登录模块
subject：本次提交主要描述信息
提交commit信息禁止出现 111/提交/commit/测试 此类无标识、无意义的的信息。
提交内容尽可能准确描述本次提交修改内容。多个修改特性可以分次提交
body: 内容主体信息。subject主要用于简短概括。如果本次修改有额外补充细节信息。则可以在此段区域进行补全
footer: 脚注。一般用于额外补充。比如是否有break-change等
¶ git提交辅助工具
当然IDE也有相关插件辅助进行提交。
-
vscode commitizen
-
jetbrains IDE:conventional-commit 、 git-commit-template
¶ 引用
¶ 发布维护规范
项目发布上线后。需要有维护
¶ 合并/清理分支
- 项目上线后将当次release/xx分支合并进master
- 删除相关release/xx分支与对应feature分支
- 打版本Tag
¶ 生产版本Tag
版本号管理遵循 Semantic Versioning 2.0.0：
- 主版本（重大变更）
- 次版本（向下兼容功能）
- 修订版本（问题修复）
¶ 功能分支定期合并master主分支
功能分支定期合并主干分支。可通过 rebase / merge方式进行合并