统一的团队协作标准,让代码提交更规范、更高效
English | 简体中文
本规范旨在为 Nestmold 团队提供一套统一、清晰的 Git 工作流程，确保多人协作时代码管理的规范性和可追溯性。
## 问题描述
<!-- 简要描述遇到的问题或需要实现的功能 -->
## 问题类型
- [ ] Bug 修复
- [ ] 新功能
- [ ] 性能优化
- [ ] 文档更新
- [ ] 代码重构
- [ ] 其他
## 重现步骤（Bug 专用）
1.
2.
3.
## 期望行为
<!-- 描述你期望发生什么 -->
## 实际行为
<!-- 描述实际发生了什么 -->
## 环境信息
- 操作系统:
- 浏览器/版本:
- Node.js 版本:
- 项目版本:
## 截图
<!-- 如果适用，添加截图帮助解释问题 -->
## 补充信息
<!-- 添加任何其他有助于理解问题的信息 -->| 标签 | 颜色 | 说明 | 示例 |
|---|---|---|---|
bug |
🔴 红色 | 程序错误 | 登录失败、数据丢失 |
feature |
🟢 绿色 | 新功能需求 | 添加用户中心、新增导出功能 |
enhancement |
🔵 蓝色 | 功能优化 | 提升加载速度、改进UI |
documentation |
📝 黄色 | 文档相关 | 更新README、补充API文档 |
refactor |
🟣 紫色 | 代码重构 | 优化代码结构、去除冗余 |
performance |
⚡ 橙色 | 性能问题 | 内存泄漏、响应慢 |
security |
🔒 黑色 | 安全问题 | SQL注入、XSS漏洞 |
wontfix |
⚪ 灰色 | 不会修复 | 已确认不需要处理 |
[类型] 简短描述
[BUG]- Bug 修复[FEAT]- 新功能[OPT]- 优化[DOC]- 文档[REFACTOR]- 重构
[BUG] 用户登录后session丢失
[FEAT] 添加用户权限管理模块
[OPT] 优化首页加载速度
[DOC] 补充API接口文档
[REFACTOR] 重构用户服务层代码graph TD
A[创建 Issue] --> B{分配负责人}
B --> C[创建开发分支]
C --> D[开发并关联 Issue]
D --> E[提交 PR]
E --> F{Code Review}
F -->|通过| G[合并代码]
F -->|不通过| D
G --> H[关闭 Issue]
# 关联单个 Issue
git commit -m "feat: 实现用户登录功能 #123"
# 关闭 Issue
git commit -m "fix: 修复登录验证bug closes #123"
git commit -m "fix: 修复登录验证bug fixes #123"
# 关联多个 Issue
git commit -m "feat: 完成用户模块 #123 #124 #125"#123- 引用 Issuecloses #123/fixes #123- 合并后自动关闭 Issuerelates to #123- 相关联但不自动关闭
| 状态 | 说明 | 后续动作 |
|---|---|---|
Open |
新建/待处理 | 等待分配 |
In Progress |
开发中 | 定期更新进度 |
Code Review |
代码审查中 | 等待审查通过 |
Testing |
测试中 | 等待测试结果 |
Done |
已完成 | 准备发布 |
Closed |
已关闭 | 无需后续动作 |
- ✅ 一个 Issue 只处理一个问题
- ✅ 标题简洁明了，使用前缀标识类型
- ✅ 提供完整的环境信息和重现步骤
- ✅ 及时更新 Issue 状态和进度
- ✅ 在 Commit 中关联相关 Issue
- ✅ 添加适当的标签和负责人
- ✅ 关闭 Issue 时说明原因
- ❌ 一个 Issue 包含多个不相关的问题
- ❌ 标题模糊不清，如"有问题"、"出错了"
- ❌ 缺少重现步骤和环境信息
- ❌ 长期不更新 Issue 状态
- ❌ 忘记关联相关的 Commit
- ❌ 随意关闭未解决的 Issue
- ❌ 重复创建相同的 Issue
<分支类型>/<版本号>/<姓名>-<具体功能>[-<子功能>]
当一个复杂功能需要多人协作或并行开发时，建议拆分为多个子分支：
dev/1.0.0/wzl-用户中心-crud # 用户增删改查功能
dev/1.0.0/wzl-用户中心-stats # 用户统计功能小功能或单人负责的功能可以在同一分支下完成：
dev/1.0.0/wzl-用户中心-优化| 分支类型 | 说明 | 示例 |
|---|---|---|
main |
生产环境主分支，始终保持可部署状态 | main |
release |
稳定版本归档，按版本号管理 | release/v1.0.0 |
preview |
预发布环境，与生产数据互通 | preview |
test |
测试环境，功能验证 | test/v1.0.0 |
dev |
开发环境，功能开发 | dev/1.0.0/xxx-功能 |
main分支不允许创建任何二级分支- 所有新需求必须从
main分支单独签出 - 分支命名应清晰表达功能意图
graph TD
A[从 main 签出] --> B[dev 分支开发]
B --> C[合并到 test]
C --> D{测试环境验证}
D -->|通过| E[合并到 preview]
D -->|不通过| B
E --> F{预发布验证}
F -->|通过| G[合并到 main]
F -->|不通过| C
G --> H[打 tag 到 release]
-
开发阶段
# 从 main 创建开发分支 git checkout main git checkout -b dev/1.0.0/wzl-用户中心 # 开发并提交 git add . git commit -m "feat: 实现用户中心基础功能"
-
测试阶段
# 合并到 test 分支 git checkout test/v1.0.0 git merge dev/1.0.0/wzl-用户中心 -
预发布阶段
# 测试通过后，合并到 preview git checkout preview git merge test/v1.0.0 -
生产部署
# 预发布验证通过，合并到 main git checkout main git merge preview # 打版本标签 git tag -a v1.0.0 -m "Release version 1.0.0" git push origin v1.0.0
| 场景 | 推荐策略 | 说明 |
|---|---|---|
| 少数人开发 | merge |
简单直接，保留完整历史 |
| 多人协作 | rebase 自己的分支 + merge 他人的分支 |
保持提交历史清晰 |
| 跨分支合并 | cherry-pick |
精选特定提交，避免冲突 |
git checkout target-branch
git merge source-branch# 在自己的分支上使用 rebase
git checkout my-feature
git rebase main
# 合并到目标分支
git checkout main
git merge my-feature# 查找需要的提交
git log --oneline
# 精选特定提交
git checkout target-branch
git cherry-pick <commit-hash>- ✅ 每个新需求都从
main分支签出 - ✅ 分支命名清晰、有意义
- ✅ 提交信息遵循规范格式
- ✅ 定期同步
main分支到开发分支 - ✅ 合并前进行 Code Review
- ✅ 功能冲突时，优先保证前序需求
- ❌ 在
main分支直接开发 - ❌ 多个需求混用同一分支
- ❌ 跳过测试直接合并到生产
- ❌ 强制推送到共享分支
- ❌ 忽略合并冲突直接提交
Q1: 如果需求有冲突怎么办？
A: 以前序需求为主，或与产品经理协商确定开发优先级。不要在同一个分支上处理冲突的需求。
Q2: Preview 环境与生产数据互通需要注意什么？
A: Preview 环境连接真实数据，务必小心操作，避免影响线上业务。建议：
- 使用只读账号进行验证
- 避免执行写入操作
- 测试完成后及时清理测试数据
Q3: 什么时候打 release tag？
A: 在 main 分支稳定运行一段时间后，确认无严重 bug，即可打 tag 归档到 release 分支。
Q4: 紧急 hotfix 如何处理？
A:
- 从
main签出hotfix/v1.0.1分支 - 修复并测试
- 合并回
main和相关开发分支 - 打新的 release tag
我们欢迎所有形式的贡献！请查看 贡献指南 了解详情。
- Fork 本仓库
- 创建特性分支 (
git checkout -b feature/AmazingFeature) - 提交更改 (
git commit -m 'Add some AmazingFeature') - 推送到分支 (
git push origin feature/AmazingFeature) - 创建 Pull Request
- v1.0.0 - 初始版本，建立基础规范
- 查看所有版本: Releases
本项目采用 MIT 许可证 - 查看 LICENSE 文件了解详情。
用 ❤️ 打造更好的团队协作体验