Commitizen 安装指南（git cz）

Commitizen 安装指南

一、安装前准备

• 安装 Commitizen 之前，务必确保已安装 Node.js 和 npm。
• 可在命令行输入 node -v 与 npm -v 来检验其安装状况及对应版本号。

二、全局安装

（一）安装步骤

1. 于命令行执行 npm install -g commitizen，此操作会将 Commitizen 工具安装至全局环境，使其能在计算机的任意项目目录下被调用。例如，在多项目开发场景中，无需为每个项目单独安装 Commitizen，全局安装后可直接使用 git cz 命令。
2. 接着运行 npm install -g cz-conventional-changelog 命令，安装 cz-conventional-changelog 适配器。该适配器遵循常规提交规范，有助于生成标准且易于理解的提交信息，利于项目版本管理与变更日志生成。
3. 在用户主目录（~）下创建 .czrc 文件，并写入 {"path": "cz-conventional-changelog"} 内容。

   • 在 Linux 或 macOS 系统，可通过 echo '{ "path": "cz-conventional-changelog" }' > ~/.czrc 命令完成创建与写入；

   • 在 Windows 中，可以通过以下步骤来创建和配置.czrc文件：

     • 打开文件资源管理器，导航到用户主目录。通常是C:\Users\你的用户名。
     • 在这个目录下，右键单击空白处，选择 “新建”->“文本文档”。
     • 将新建的文本文档命名为.czrc（如果看不到文件扩展名，需要在文件资源管理器的 “查看” 选项卡中，勾选 “文件扩展名”）。
     • 右键单击.czrc文件，选择 “编辑”，在文件中输入{"path": "cz-conventional-changelog"}，然后保存文件。

   • 或者在git bash中输入命令：echo '{ "path": "cz-conventional-changelog" }' > ~/.czrc会直接在用户主目录生成.czrc文件。

（二）优点

1. 便捷性：全局安装完成后，在任何新项目或已有项目中均可直接使用 git cz 命令，无需在各项目重复安装与配置相关依赖，大幅节省时间与精力，尤其适用于频繁切换不同项目开发的情况。
2. 一致性：能确保所有项目遵循相同提交规范（由所安装适配器决定，如 cz-conventional-changelog），使提交历史格式与风格统一，便于团队成员协作、代码审查，以及后续对项目整体变更情况的分析与总结。

（三）缺点

1. 缺乏灵活性：若不同项目需采用不同提交规范或有特殊提交要求，全局安装方式可能无法满足。因全局配置应用于所有项目，更改全局配置可能影响其他原本正常工作的项目。
2. 版本冲突风险：全局安装的 Commitizen 及其相关依赖可能与某些项目中已有其他依赖版本不兼容。例如，某项目因其他原因依赖旧版本 cz-conventional-changelog 或 Commitizen，全局安装的新版本可能导致该项目使用 git cz 时出现错误或异常。

三、项目内安装

（一）安装步骤

1. 进入项目目录，在命令行运行 npm install --save-dev commitizen 命令，将 Commitizen 安装为项目开发依赖，仅在当前项目环境中可用，不影响其他项目。
2. 随后执行 commitizen init cz-conventional-changelog --save-dev --save-exact 命令，初始化项目使用 cz-conventional-changelog 规范。此操作会在项目的 package.json 中添加相关配置信息，或创建 .czrc 文件（依项目情况而定），这些配置用于指导 Commitizen 在该项目中引导用户生成符合规范的提交消息。

（二）优点

1. 项目特定定制：可针对每个项目特殊需求灵活配置不同提交规范与相关参数。例如，某项目需遵循特定内部提交规范而非通用 cz-conventional-changelog 规范，可在项目内安装时选择合适适配器或自定义配置，不影响其他项目提交规范设置。
2. 避免版本冲突：因 Commitizen 及其相关依赖安装在项目内部，与项目其他依赖共同管理，可更好控制版本兼容性。即便全局安装不同版本 Commitizen 或相关依赖，项目内安装版本也能独立运行，不受全局环境干扰，降低因版本冲突导致项目问题的风险。

（三）缺点

1. 安装冗余：若多个项目需使用相同提交规范与 Commitizen 配置，需在各项目重复安装与配置相关依赖，增加工作量与项目存储占用，项目数量较多时冗余更明显。
2. 维护成本：每个项目都有独立 Commitizen 安装与配置，意味着更新或维护提交规范时，需分别对各项目操作，无法像全局安装那样一次性在所有项目应用更新，增加维护复杂性与成本。

无论是全局安装还是项目内安装，均有各自特点与适用场景。实际开发中，可依据团队开发习惯、项目具体需求以及提交规范统一管理要求等因素，选择合适安装方式来使用 git cz，以提升项目开发过程中代码提交管理效率与质量。

• feat 新功能
• fix BUG修复
• docs 仅文档变更
• style 不影响代码含义的变更（空格、格式、缺失分号等）
• refactor 既不修复错误也不添加新功能的代码变更
• perf 提升性能的代码变更
• test 添加缺失的测试或修正已有的测试
• build 影响构建系统或外部依赖的变更（例如作用域：gulp、broccoli、npm）
• ci 对持续集成配置文件和脚本的变更（例如作用域：Travis、Circle、BrowserStack、SauceLabs）
• chore 其他不修改源文件或测试文件的变更