mmdoc

Appearance

开发项目管理规范 ​

概述 ​

本规范旨在为软件开发项目提供一个规范化的项目管理指南，以确保项目能够按时、按质量要求完成，并提高团队协作效率和项目交付的成功率。该规范适用于所有软件开发程序员参与的项目，包括需求分析、设计、编码、测试和部署等阶段

修订日志 ​

更新日期更新人更新说明
2024年01月15日胡祥初始化文档

项目GIT仓库管理 ​

仓库创建规范 ​

  • 公司交付项目必须通过员工平台-项目git创建功能进行项目创建

  • 若有项目存在无法适用情况。则由部门经理进行项目创建工作。并提报至架构部。架构部人员负责收集处理。并将项目模板提供至员工平台

  • 部门经理负责项目创建核查。质检部以及架构部不定期进行检查。

  • 必须符合项目命名规范。

  • 开发者禁止给与项目管理员权限。

  • 仓库可见性必须为私有。(员工平台创建默认为私有)

  • 仓库描述补全。（楼兰微信小程序，楼兰后台）。

仓库命名规范 ​

项目命名规范。用于约束git项目命名规则。有助于项目管理与追溯。其命名规则如下

LX{no}-{name}-{flag}。

其中:

  • no: 为项目编号。员工平台项目立项后生成的项目编号。通过员工平台创建的git会自动携带。无需开发人员填写

  • name: 项目名称的中文拼音。例如：标准商城(biaozhunshangcheng)

  • flag: 为项目标识。用于区分不通的项目类型。具体类型如下

    • admin JAVA系统
    • backend 后台系统
    • app app项目
    • weapp 微信小程序
    • fronted 前端项目。此种命名风格比较宽泛。适用于使用Taro开发框架的项目
    • PC web pc 端
    • H5 web 手机端（公众号也包括在内）

如有遗漏。提出补充

GIT代码管理规范 ​

  • 规范第一条: 公司任何代码不允许上传至任何三方开源平台(如:GitHub、Gitee、码云等)
    所有公司项目都涉及商业合作和法律问题。因此，所有参与项目开发的人员都有责任和义务保护公司和甲方客户的商业生产资料。如果由于员工个人原因导致源代码泄露造成客户损失的，客户和公司都有权依法追究法律责任。员工将自行承担由此造成的所有损失。

GIT Commit 规范 ​

代码提交规范 遵循 GIT 提交规范

目的 ​

  • 统一团队 Git commit 日志标准，便于后续代码 review，版本发布以及日志自动化生成等等。

  • 统一团队的 Git 工作流，包括分支使用、tag 规范、issue 等

使用方案 ​

bash
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

所有的 type 类型如下： type代表某次提交的类型，比如是修复一个bug还是增加一个新的feature。

  • feat: 新增 feature
  • fix: 修复 bug
  • docs: 仅仅修改了文档，比如 README, CHANGELOG, CONTRIBUTE等等
  • style: 仅仅修改了空格、格式缩进、逗号等等，不改变代码逻辑
  • refactor: 代码重构，没有加新功能或者修复 bug
  • perf: 优化相关，比如提升性能、体验
  • test: 测试用例，包括单元测试、集成测试等
  • chore: 改变构建流程、或者增加依赖库、工具等
  • revert: 回滚到上一个版本

引用 ​

Git分支与版本发布规范 ​

git分支管理 基于 Git Flow 思想进行管理。在此基础上。总结适合本司情况的仓库管理方案。具体为：

  • 基本原则：master为保护分支，不直接在master上进行代码修改和提交。

  • 开发日常需求或者项目时，从master分支上checkout一个feature分支进行开发或者bugfix分支进行bug修复，功能测试完毕并且项目发布上线后，将feature分支合并到主干master，并且打Tag发布，最后删除开发分支。

  • 多人(2人以上)以及长期、大型、战略项目。
    master分支仅作发布使用。
    dev分支作为开发分支
    uat分支,依据实际情况。是否使用此分支发布测试环境。

  • feat_{name}功能分支: 功能开发分支。基于开发分支迁出，某项功能开发分支。开发完成后合并进开发分支

  • hotfix_{name}: 线上问题修复分支。

  • fix_{name}: 功能修复分支

  • refactor_{name}: 代码重构分支

  • Tag: git标签。当项目发布上线时。需要在当前代码提交节点创建Tag。具体规则为v{major}.{minor}.${patch}。其中major 为主功能调整。通常是表示此次迭代涉及重大业务逻辑调整等。minor为为此版本号。通常意味着是功能迭代。patch为修订版本。通常意义为线上bug修复。

Git管理工具接入 ​

目前针对git提交规范。有相关检查工具。用于约束git提交。不满足格式的提交将会被拒绝。在本文档修订过程中。框架暂不强制约束。请各位开发同学自行安装测试。本部门会在适当阶段对所有框架进行接入。

创建依赖 ​

在项目根目录中的package.json文件中添加下面依赖

json
 {
    "name": "application-name",
    "version": "0.1.0",
    "scripts": {
      "commitmsg": "validate-commit-msg",
      "commit": "git-cz ",
      "changelog": "conventional-changelog -p angular -i CHANGELOG.md -s -r 0"
    },
    "devDependencies": {
      "commitizen": "^2.3.0",
      "validate-commit-msg": "^2.11.1",
      "conventional-changelog-cli": "^1.2.0",
      "husky": "^0.13.1"
    }
  }

在工程根目录新建.vcmrc文件 ​

文件内容为

json
{
  "helpMessage": "\nPlease fix your commit message (and consider using https://www.npmjs.com/package/commitizen)\n",
  "types": [
    "feat",
    "fix",
    "docs",
    "style",
    "refactor",
    "perf",
    "test",
    "chore",
    "revert"
  ],
  "warnOnFail": false,
  "autoFix": false
}

测试 ​

  • 第一步：创建一个feature分支或者bugfix分支
bash
  git checkout -b feature_测试    # 切换到一个feature分支或者bug fix分支
  • 第二步：将代码提交到本地Git仓库，并填写符合要求的Commit message格式
bash
  git add .
  git commit   # 此处不要加任何参数，比如-m

此时终端会打开提交编辑器。进行规范提交

vim
doc(document): 测试提交规范
  • 第三步：将代码同步到远程Git仓库
bash
  git push origin feature_infinite_load    # 将修改发布到远程仓库

如果提交失败。则表示规范约束成功。如果提交成功。则表示约束失败。

约束成功后。我们修改一下格式

bash
  git commit --amend

并且修改文案为: docs(document): 测试提交规范。 保存后执行第三步。此时。提交成功

  • 第四步：自动生成changelog，并打Tag发布
bash
 npm run changelog   # 使用npm script中的changlog命令直接从git元数据生成日志。