From fb4cde6239f31c1cdf0a20ee8c3b19d429fb5dbc Mon Sep 17 00:00:00 2001
From: luke <luke.k.xu@hotmail.com>
Date: Sun, 8 Jun 2025 21:19:19 +0800
Subject: [PATCH] =?UTF-8?q?docs:=20=E5=A2=9E=E5=8A=A0=E7=83=AD=E4=BF=AE?=
 =?UTF-8?q?=E5=A4=8D?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 doc/Git-Management/Git-Management.md | 74 +++++++++++++++-------------
 1 file changed, 41 insertions(+), 33 deletions(-)

diff --git a/doc/Git-Management/Git-Management.md b/doc/Git-Management/Git-Management.md
index 70575d1..5f12e99 100644
--- a/doc/Git-Management/Git-Management.md
+++ b/doc/Git-Management/Git-Management.md
@@ -4,53 +4,66 @@
 
 本项目使用 Git 进行版本控制，并遵循以下基本原则：
 
-* 所有代码更改必须通过 Git 提交并推送到远程仓库。
-* 每次提交都应包括清晰、简洁且具描述性的提交信息，便于团队成员理解变更目的。
-* 严禁直接在 `main` 分支上进行开发，所有功能开发应通过分支进行。
+* 所有代码更改必须通过 Git 提交，并推送至远程仓库。
+* 每次提交必须包括清晰、简洁且具描述性的提交信息，确保团队成员能够轻松理解变更的目的和内容。
+* 严禁直接在 `main` 分支上进行开发。所有功能开发必须通过独立分支进行。
 
 ## 2. 分支管理
 
-本项目采用以下分支策略以高效管理代码：
+本项目采用以下分支策略进行代码管理：
 
 ### 2.1 主分支 (`main`)
 
-* **用途**：`main` 分支始终保持项目的稳定版本，该分支的代码可随时部署到生产环境。
-* **更新规则**：仅允许经过充分测试并审核的代码合并至 `main` 分支。每次从 `dev` 或 `release` 分支合并到 `main` 时，需打上版本标签。
+* **用途**：`main` 分支始终保持项目的稳定版本，且此分支的代码随时可以部署到生产环境。
+* **更新规则**：仅允许经过充分测试并审查的代码合并到 `main` 分支。每次从 `dev` 或 `release` 分支合并到 `main` 时，必须打上版本标签。
 
 ### 2.2 开发分支 (`dev`)
 
-* **用途**：`dev` 分支作为所有开发工作的集成分支。所有新功能开发应首先合并至 `dev` 分支，经过集成测试后再合并到 `main`。
-* **更新规则**：团队成员应从 `dev` 分支拉取最新代码，完成开发后将功能合并回 `dev`。
+* **用途**：`dev` 分支是所有开发工作的集成分支。所有的新功能开发应首先合并至 `dev` 分支，并经过集成测试后再合并到 `main`。
+* **更新规则**：所有功能开发完成后，应合并至 `dev` 分支进行集成测试，确认没有问题后再合并到 `main`。
 
 ### 2.3 功能分支 (`feature/*`)
 
-* **用途**：每个新功能开发应从 `dev` 分支创建独立的功能分支。
-* **命名规范**：`feature/功能描述`，例如：`feature/AST`、`feature/user-cli`。
+* **用途**：每个新功能的开发都应从 `dev` 分支创建一个独立的功能分支。
+* **命名规范**：`feature/功能描述`，例如：`feature/ast-folding`、`feature/user-cli`。所有分支名称应使用小写字母，并且使用破折号（`-`）分隔单词。
 * **开发流程**：
 
   1. 从 `dev` 分支拉取最新代码。
   2. 完成功能开发后，在本地提交代码并推送至远程仓库。
-  3. 创建拉取请求（PR），合并至 `dev` 分支。
+  3. 创建拉取请求（PR），并合并到 `dev` 分支。
 
 ### 2.4 修复分支 (`bugfix/*`)
 
-* **用途**：用于修复 bugs。修复分支可从 `dev` 或 `main` 分支创建。
-* **命名规范**：`bugfix/bug描述`，例如：`bugfix/fix-AST-error`。
+* **用途**：用于修复 Bug，修复分支可以从 `dev` 或 `main` 分支创建。
+* **命名规范**：`bugfix/bug描述`，例如：`bugfix/fix-ast-error`。
 * **开发流程**：
 
   1. 从 `dev` 或 `main` 分支拉取最新代码。
   2. 完成修复后，提交修改并推送至远程仓库。
-  3. 创建 PR，合并至相应分支。
+  3. 创建拉取请求（PR），并合并到相应分支。
 
 ### 2.5 发布分支 (`release/*`)
 
-* **用途**：当 `dev` 分支的功能开发完成并准备发布时，应创建 `release` 分支。
+* **用途**：当 `dev` 分支的功能开发完成且准备发布时，应创建一个 `release` 分支进行发布准备。
 * **命名规范**：`release/vX.X.X`，例如：`release/v1.0.0`。
 * **开发流程**：
 
   1. 从 `dev` 分支创建 `release` 分支。
-  2. 在 `release` 分支上完成版本发布的最终准备工作，如文档更新和版本号调整等。
-  3. 完成发布准备后，将 `release` 分支合并至 `main` 并打上版本标签，随后合并回 `dev` 分支。
+  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. 提交规范
 
@@ -68,36 +81,35 @@
 
 #### 提交类型
 
-* `feat`：新增功能（feature）
-* `fix`：修复 bug
+* `feat`：新增功能
+* `fix`：修复 Bug
 * `docs`：文档更新
 * `style`：代码格式调整（不影响功能）
 * `refactor`：代码重构
 * `test`：增加/修改测试
 * `chore`：工具配置等其他杂项任务
+* `ci`：持续集成相关改动
+* `perf`：性能优化
 
 #### 示例
 
 * `feat: 添加 IR 折叠功能`
-* `fix: 修复 IR 折叠错误`
+* `fix: 修复问题 Y（原因：X bug，解决方案：Z）`
 * `docs: 更新 API 文档`
 * `refactor: 优化 AST 逻辑`
 
 ### 3.2 提交实践
 
-* 提交时请确保代码已完成并通过所有相关测试。
-* 每次提交应包含少量且相关的变更，避免一次性提交过多内容。
+* 提交时，请确保代码已完成并通过所有相关测试。
+* 每次提交应仅包含少量且相关的变更，避免一次性提交过多内容，以便于追踪和管理。
 
-## 4. 合并和拉取请求（PR）
-
-在多人协作开发过程中，拉取请求（PR）是确保代码质量和功能完整性的核心工具。所有的代码合并都必须经过严格的代码审查和测试验证。
+## 4. 拉取请求（PR）与代码审查
 
 ### 4.1 拉取请求流程
 
 1. 开发者在完成功能或修复后，创建 PR，将其分支合并至 `dev` 或 `main` 分支。
 2. 其他团队成员进行代码审查，重点检查代码质量、功能完整性及测试覆盖率。
 3. 审查通过后，PR 将被合并。
-4. 合并时，推荐使用 **Squash and Merge** 方式，避免留下过多冗余的提交历史。
 
 ### 4.2 代码审查
 
@@ -108,6 +120,7 @@
   * 是否提供了足够的单元测试覆盖。
   * 是否存在冗余代码或复杂度过高的部分。
   * 功能是否按预期工作。
+  * 审查者应在 PR 中提供反馈，确保代码质量高，符合团队要求。
 
 ## 5. 版本发布
 
@@ -131,14 +144,9 @@
 2. 从 `dev` 分支创建 `release` 分支，进行版本发布的准备工作。
 3. 在 `release` 分支上完成最终修改，如文档更新和版本号调整。
 4. 将 `release` 分支合并至 `main` 并打上版本标签。
-5. 合并 `release` 分支的变更回 `dev`，确保所有修复和改动在开发分支中得到同步。
+5. 将 `release` 分支的变更合并回 `dev`，确保所有修复和改动在开发分支中得到同步。
 
 ### 5.3 发布后
 
 * 发布版本后，团队成员应确保将 `main` 分支的最新代码拉取到本地，以保持代码库的同步。
-* 如出现生产环境问题，应及时创建 `hotfix` 分支进行紧急修复。
-
-## 6. 合作与沟通
-
-* 团队成员应保持良好的沟通，特别是在合并大型功能时，确保不会出现冲突。
-* 定期进行团队会议，回顾代码审查过程并讨论开发流程和工具的改进建议。
\ No newline at end of file
+* 如出现生产环境问题，应及时创建 `hotfix` 分支进行紧急修复，并尽快发布。
\ No newline at end of file