diff --git "a/doc/Git\346\217\220\344\272\244\350\247\204\350\214\203.md" "b/doc/Git\346\217\220\344\272\244\350\247\204\350\214\203.md"
new file mode 100644
index 0000000000000000000000000000000000000000..97479318f12c52eba9cf18ddc26d6a2ad255dc82
--- /dev/null
+++ "b/doc/Git\346\217\220\344\272\244\350\247\204\350\214\203.md"
@@ -0,0 +1,50 @@
+# Git 提交规范
+
+### 一、提交前缀规范（区分类别）
+
+Git提交信息通常包括一个前缀，用于说明提交的性质。以下是一些常见的提交前缀及其含义：
+
+1. **feat**：表示新增功能（feature）的提交。例如，“feat: add new login feature”表示添加了一个新的登录功能。
+2. **fix**：表示修复错误（bug fix）的提交。例如，“fix: resolve memory leak issue”表示修复了一个内存泄漏问题。
+3. **docs**：表示文档更新的提交。例如，“docs: update user guide”表示更新了用户手册。
+4. **style**：表示代码样式修改的提交，不影响程序逻辑。例如，“style: adjust code formatting”表示调整了代码格式。
+5. **refactor**：表示代码重构的提交，即不改变代码功能的情况下优化代码结构。例如，“refactor: simplify function logic”表示简化了函数逻辑。
+6. **build**：表示影响构建系统的更改。例如，“build: upgrade webpack to version 4”表示升级了webpack到版本4。
+7. **perf**：表示性能优化的提交。例如，“perf: optimize database query”表示优化了数据库查询性能。
+8. **test**：表示测试相关的更改，如添加或修改测试用例。例如，“test: add unit tests for new feature”表示为新功能添加了单元测试。
+9. **chore**：表示其他杂项事务的提交，如更新依赖项、配置文件等。例如，“chore: update package dependencies”表示更新了包依赖。
+10. **ci**：表示持续集成相关的更改，如CI/CD配置文件的更新。例如，“ci: configure Jenkins for automated builds”表示配置了Jenkins进行自动化构建。
+
+此外，还可以添加**scope**（可选）用于说明commit的影响范围，以及**subject**（必须）作为commit的简要说明。
+
+### 二、提交文字规范
+
+除了前缀外，提交信息还应该遵循一定的文字规范：
+
+1. **简洁明了**：提交信息应该简洁明了，能够概括该次提交的主要内容。避免使用冗长或模糊的描述。
+2. **使用英文**：提交信息应该使用英文描述，以便于团队内外成员的理解。
+3. **遵循格式**：提交信息可以遵循一定的格式，比如使用一行简短的标题来概括该次提交（包含前缀、scope和subject），接下来是一行空行，再接下来是详细的描述（body部分）。
+4. **动词原形**：提交信息应该以动词原形开头，使用第一人称或第三人称来描述具体的改动。例如，“Add new feature”或“Fix existing bug”。
+5. **关联issue**：如果本次提交涉及到关闭一个issue或解决一个问题，可以在提交信息中关联相关的issue号码。例如，“Close issue #123”。
+
+### 三、单次提交注意事项
+
+1. **提交问题必须为同一类别**：一次提交应该只包含同一类别的改动。例如，不要将新功能添加和bug修复放在同一个提交中。
+2. **提交问题数量限制**：一次提交的问题数量应该控制在合理范围内，通常建议不超过3个。这有助于保持提交历史的清晰和易于理解。
+3. **修正不符合规范的提交**：如果发现提交的commit信息不符合规范，可以使用`git commit --amend -m "新的提交信息"`或`git reset --hard HEAD^`重新提交一次。
+
+### 四、分支命名规范
+
+除了提交信息规范外，良好的分支命名规范也是提高团队协作效率的重要因素。以下是一些建议的分支命名规范：
+
+1. **主分支**：通常使用`master`或`main`作为主分支的名称，用于存储稳定的版本代码。不建议在主分支上直接开发。
+2. **开发分支**：通常使用`develop`作为开发分支的名称，用于整合并存储开发者的代码。所有的新功能或修复的bug都应该在自己的分支上进行开发，并从`develop`分支创建出对应的功能分支。
+3. **功能分支**：用于开发新功能或修复bug的分支。命名建议采用有意义的名称，可以描述该分支要解决的问题或实现的功能。例如，`feature/new-login`表示开发一个新的登录功能。
+4. **发布分支**：用于准备发布的版本的分支。命名规范可以是`release/v{version-number}`，例如`release/v1.0`表示准备发布版本1.0。
+5. **临时分支**：用于临时的实验性开发等。命名规范可以是`temp/{branch-name}`。
+
+### 五、其他规范
+
+1. **频繁提交**：在开发过程中，建议频繁提交代码到版本控制系统，以便于跟踪和回滚。每个提交应该只包含一个独立的变更。
+2. **代码审查**：在合并分支之前，可以进行代码审查，确保代码质量和风格的一致性。这有助于提高代码的可读性和可维护性。
+3. **使用Git工具**：使用Git工具可以提高效率和准确性。例如，Git GUI、Git Bash等可以帮助开发者熟练掌握常用的Git操作命令。