commit 3ba5943ec1a30e0bc24e0e5931ee88be3c252446
Author: luke <luke.k.xu@hotmail.com>
Date:   Fri Aug 22 09:26:20 2025 +0800

    添加 Git 管理规范.md

diff --git a/Git 管理规范.md b/Git 管理规范.md
new file mode 100644
index 0000000..0d60b90
--- /dev/null
+++ b/Git 管理规范.md	
@@ -0,0 +1,270 @@
+# Git 管理规范
+
+## 1. 版本控制基础
+
+使用 Git 进行版本控制，并遵循以下基本原则: 
+
+* 所有代码更改必须通过 Git 提交，并推送至远程仓库。
+* 每次提交必须包括清晰、简洁且具描述性的提交信息，确保团队成员能够轻松理解变更的目的和内容。
+* 严禁直接在 `main` 分支上进行开发。所有功能开发必须通过独立分支进行。
+
+## 2. 分支管理
+
+本项目采用以下分支策略进行代码管理: 
+
+### 2.1 主分支 (`main`)
+
+* **用途**: `main` 分支始终保持项目的稳定版本，且此分支的代码随时可以部署到生产环境。
+* **更新规则**: 仅允许经过充分测试并审查的代码合并到 `main` 分支。每次从 `dev` 或 `release` 分支合并到 `main` 时，必须打上版本标签。
+
+### 2.2 开发分支 (`dev`)
+
+* **用途**: `dev` 分支是所有开发工作的集成分支。所有的新功能开发应首先合并至 `dev` 分支，并经过集成测试后再合并到 `main`。
+* **更新规则**: 所有功能开发完成后，应合并至 `dev` 分支进行集成测试，确认没有问题后再合并到 `main`。
+
+### 2.3 功能分支 (`feature/*`)
+
+* **用途**: 每个新功能的开发都应从 `dev` 分支创建一个独立的功能分支。
+* **命名规范**: `feature/功能描述`，例如: `feature/ast-folding`、`feature/user-cli`。所有分支名称应使用小写字母，并且使用破折号（`-`）分隔单词。
+* **开发流程**: 
+
+  1. 从 `dev` 分支拉取最新代码。
+  2. 完成功能开发后，在本地提交代码并推送至远程仓库。
+  3. 创建拉取请求（PR），并合并到 `dev` 分支。
+
+### 2.4 修复分支 (`bugfix/*`)
+
+* **用途**: 用于修复 Bug，修复分支可以从 `dev` 或 `main` 分支创建。
+* **命名规范**: `bugfix/bug描述`，例如: `bugfix/fix-ast-error`。
+* **开发流程**: 
+
+  1. 从 `dev` 或 `main` 分支拉取最新代码。
+  2. 完成修复后，提交修改并推送至远程仓库。
+  3. 创建拉取请求（PR），并合并到相应分支。
+
+### 2.5 发布分支 (`release/*`)
+
+* **用途**: 当 `dev` 分支的功能开发完成且准备发布时，应创建一个 `release` 分支进行发布准备。
+* **命名规范**: `release/vX.X.X`，例如: `release/v1.0.0`。
+* **开发流程**: 
+
+  1. 从 `dev` 分支创建 `release` 分支。
+  2. 在 `release` 分支上进行版本发布的最终准备工作，如文档更新、版本号调整等。
+  3. 完成发布准备后，将 `release` 分支合并至 `main` 并打上版本标签，随后将变更合并回 `dev` 分支。
+
+### 2.6 热修复分支 (`hotfix/*`)
+
+* **用途**: 当生产环境中发现紧急问题（如 Bug 或系统崩溃等），需在 `main` 分支上进行快速修复时，应创建一个 `hotfix` 分支进行修复。
+* **命名规范**: `hotfix/bug描述`，例如: `hotfix/fix-production-crash`。
+* **开发流程**: 
+
+  1. 从 `main` 分支创建 `hotfix` 分支，确保该分支包含生产环境中最新的稳定版本。
+  2. 在 `hotfix` 分支上进行问题修复和相关调整。
+  3. 完成修复后，提交修改并推送至远程仓库。
+  4. 创建拉取请求（PR），将 `hotfix` 分支合并至 `main` 分支并打上版本标签，确保生产环境修复生效。
+  5. 将修复后的变更合并回 `dev` 分支，确保所有的修复和调整同步到开发分支，防止后续开发中出现同样的问题。
+  6. **回滚策略**: 如果热修复未能解决问题，立即回滚合并，删除 `hotfix` 分支并通知团队，确保不影响生产环境。
+
+## 3. 提交规范
+
+为确保提交信息清晰且易于理解，遵循以下提交规范: 
+
+### 3.1 提交信息格式
+
+提交信息应简洁且具有描述性，格式如下: 
+
+```
+[类型] 描述
+
+详细描述（可选）
+```
+
+#### 提交类型
+
+* `feat`: 新增功能
+* `fix`: 修复 Bug
+* `docs`: 文档更新
+* `style`: 代码格式调整（不影响功能）
+* `refactor`: 代码重构
+* `test`: 增加/修改测试
+* `chore`: 工具配置等其他杂项任务
+* `ci`: 持续集成相关改动
+* `perf`: 性能优化
+
+#### 示例
+
+* `feat: 添加 IR 折叠功能`
+* `fix: 修复问题 Y（原因: X bug，解决方案: Z）`
+* `docs: 更新 API 文档`
+* `refactor: 优化 AST 逻辑`
+
+### 3.2 提交实践
+
+* 提交时，请确保代码已完成并通过所有相关测试。
+* 每次提交应仅包含少量且相关的变更，避免一次性提交过多内容，以便于追踪和管理。
+
+## 4. 拉取请求（PR）与代码审查
+
+### 4.1 拉取请求流程
+
+1. 开发者在完成功能或修复后，创建 PR，将其分支合并至 `dev` 或 `main` 分支。
+2. 其他团队成员进行代码审查，重点检查代码质量、功能完整性及测试覆盖率。
+3. 审查通过后，PR 将被合并。
+
+### 4.2 代码审查
+
+* 所有 PR 必须经过至少一名开发者的代码审查。
+* 审查时应关注以下方面: 
+
+  * 代码是否符合项目的编码规范。
+  * 是否提供了足够的单元测试覆盖。
+  * 是否存在冗余代码或复杂度过高的部分。
+  * 功能是否按预期工作。
+  * 审查者应在 PR 中提供反馈，确保代码质量高，符合团队要求。
+
+## 5. 版本发布
+
+版本发布基于 Git 标签，发布流程如下: 
+
+### 5.1 打标签
+
+每当版本准备发布时，应在 `main` 分支上打上版本标签: 
+
+* **版本号规则**: 采用语义化版本控制（SemVer）格式，版本号由三部分组成: `主版本号.次版本号.修订号`（例如: `v1.0.0`）。
+* **标签命令**: 
+
+  ```bash
+  git tag v1.0.0
+  git push origin v1.0.0
+  ```
+
+### 5.2 发布流程
+
+1. 确保所有功能已合并至 `dev` 分支，并通过集成测试。
+2. 从 `dev` 分支创建 `release` 分支，进行版本发布的准备工作。
+3. 在 `release` 分支上完成最终修改，如文档更新和版本号调整。
+4. 将 `release` 分支合并至 `main` 并打上版本标签。
+5. 将 `release` 分支的变更合并回 `dev`，确保所有修复和改动在开发分支中得到同步。
+
+### 5.3 发布后
+
+* 发布版本后，团队成员应确保将 `main` 分支的最新代码拉取到本地，以保持代码库的同步。
+* 如出现生产环境问题，应及时创建 `hotfix` 分支进行紧急修复，并尽快发布。
+
+
+```mermaid
+flowchart LR
+  %% ---------- Core dev cycle ----------
+  subgraph CORE[Core Flow]
+    direction LR
+    F[Feature] --> D[Dev] --> R[Release] --> M[Main] --> P[Production]
+    R --> D
+  end
+
+  %% ---------- Fix streams grouped ----------
+  subgraph FIX[Fix Streams]
+    direction TB
+    B[Bugfix]
+    H[Hotfix]
+  end
+
+  %% Bugfix: can start from Dev or Main, merges back to both
+  D -. create .-> B
+  M -. create .-> B
+  B --> D
+  B --> M
+
+  %% Hotfix: from Main, then merge back to Main & Dev
+  M -. create .-> H
+  H --> M
+  H --> D
+
+  %% ---------- Styling ----------
+  classDef core fill:#EEF5FF,stroke:#5B8DEF,stroke-width:2px,rx:10,ry:10;
+  classDef branch fill:#F6F5FF,stroke:#9B87F5,rx:10,ry:10;
+  classDef hot fill:#FFF5F5,stroke:#F56565,stroke-width:2px,rx:10,ry:10;
+  classDef env fill:#E8FFF8,stroke:#2C7A7B,stroke-width:2px,rx:10,ry:10;
+
+  class D,R,M core;
+  class F,B branch;
+  class H hot;
+  class P env;
+
+
+```
+
+
+### 简要说明
+
+* **主流程**：所有开发都在 `feature/` 或 `bugfix/` 分支，合并至 `dev`，再经过 `release/` 到 `main`。
+* **发布**：`release/` 分支只用于准备发布，合并后要打 Tag 并同步回 `dev`。
+* **热修复**：`hotfix/` 从 `main` 分支拉出，紧急修复后要同时同步回 `main` 和 `dev`。
+* **所有分支** 推荐通过 **PR（拉取请求）** 合并，需经过代码审查。
+
+
+## 6. Issue 管理规范
+
+### 6.1 Issue 基础
+
+* **用途**:
+  Issue 用于跟踪项目中的任务、功能需求、Bug 报告以及改进建议。
+  每个 Issue 都应有明确的描述，方便开发者理解并处理。
+
+* **基本要求**:
+
+  * 每个功能开发、Bug 修复都应有对应的 Issue。
+  * 在提交 PR 时，应在描述中关联对应的 Issue（如 `close #123` 或 `resolve #123`）。
+  * Issue 状态应及时更新，避免长期挂起。
+
+---
+
+### 6.2 Issue 分类
+
+为保证管理清晰，建议使用以下标签（Label）对 Issue 分类：
+
+* **类型标签**:
+
+  * `bug`: 缺陷或错误修复
+  * `feature`: 新功能开发
+  * `enhancement`: 功能改进或优化
+  * `docs`: 文档相关
+  * `discussion`: 需要团队讨论的主题
+
+* **优先级标签**:
+
+  * `priority: high`（高优先级，需立即处理）
+  * `priority: medium`（中优先级，近期处理）
+  * `priority: low`（低优先级，长期计划）
+
+---
+
+### 6.3 Issue 流程
+
+1. **创建 Issue**
+
+   * 明确问题或需求，写清楚背景、预期结果和实际情况。
+   * 必要时提供截图、日志或代码片段。
+
+2. **分配 Issue**
+
+   * 项目负责人或团队成员可将 Issue 分配给具体开发者。
+   * 复杂的 Issue 建议先进行评估，再拆分为子任务。
+
+3. **处理 Issue**
+
+   * 开发者在新建分支（如 `feature/*`、`bugfix/*`、`hotfix/*`）时，应在分支说明或 PR 中关联对应的 Issue。
+   * 处理完成后，提交 PR 并关联 Issue。
+
+4. **关闭 Issue**
+
+   * 当 PR 合并后，相关 Issue 自动关闭。
+   * 如果问题未解决，应重新打开或创建新的 Issue。
+
+---
+
+### 6.4 Issue 最佳实践
+
+* **描述清晰**：避免模糊描述，如“修复报错”；应写明“修复用户登录时因 token 校验失败导致的 500 错误”。
+* **一个 Issue 只包含一个问题**：避免一个 Issue 同时涉及多个 Bug 或功能需求。
+* **保持更新**：在处理过程中，及时补充进展，方便团队成员了解状态。
+* **结合 Milestone**：将 Issue 归档到迭代或版本里，保证任务有明确的交付目标。
\ No newline at end of file