Label Create

1. GitHub Labels 常用命名规范#

在使用 GitHub Labels 时，混乱的命名会让 Issue 面板变得难以维护。一个优秀的命名体系应当具备可读性强、易于分类和自动排序友好的特点。

目前主流的命名方式主要分为两种：扁平化命名和前缀/范围命名。

1.1 扁平化命名 (Flat Naming)#

这是 GitHub 默认的风格，适合小型项目或个人项目。所有标签都是独立的单词，简单直接。

命名格式：kebab-case (小写字母，短横线连接)

常用词汇：

• bug
• enhancement (或 feature)
• documentation
• duplicate
• question

缺点就是：当标签数量超过 10 个时，列表会变得杂乱无章，难以一眼区分类型还是状态。

1.2 前缀/范围命名 (Scoped Naming) —— ⭐️ 推荐#

在中大型开源项目（如 Vue, React, Kubernetes）中，通用的最佳实践是使用 Scoped Naming。通过使用冒号 : 或斜杠 / 将标签分组。

核心优势：GitHub 的标签列表是按字母顺序排序的。使用前缀可以让同一类标签自动聚在一起，视觉上极其整洁。

• type: ... (变更类型)
  • 定义 “这到底是一个什么性质的改动”。
  • 示例：type: bug, type: feature, type: chore, type: refactor
• status: ... (当前状态)
  • 定义 Issue 目前处于生命周期的哪个阶段。
  • 示例：status: pending, status: help wanted, status: wontfix
• priority: ... (优先级)
  • 定义处理的紧急程度。
  • 示例：priority: high, priority: medium, priority: low
• area: ... (涉及领域/组件)
  • 区分前后端或不同模块。
  • 示例：area: frontend, area: backend, area: database

1.3 常用命名清单#

无论你选择扁平化还是带前缀，这些关键词是业界通用的 “标准词汇”，建议直接采纳：

1.3.1. 代码变更类 (对应 Git Commit 类型)#

• bug / fix：错误修复
• feat / feature：新功能
• docs / documentation: 文档
• style: 格式（空格、分号等）
• refactor: 代码重构
• perf / performance: 性能优化
• test: 测试相关
• chore: 构建/杂项

1.3.1. 流程管理类#

• wontfix: 不予修复
• duplicate: 重复
• invalid: 无效
• question: 咨询/提问

1.3.2. 社区友好类#

• good first issue: 适合新手
• help wanted: 需要帮助

2. Label 的描述#

在 GitHub 中，Label 的 Description（描述） 非常重要。当鼠标悬停在标签上时，会显示这段文字。一段清晰的描述能帮助贡献者（尤其是新手）快速理解标签的含义，避免乱贴标签。

Label 的名称通常很简短（如 chore），可能无法完全传达语境。Description 的作用就是补充说明 “什么情况下该用这个标签”。

以下是常用标签的标准英文描述（与 GitHub 默认预设保持一致）及其对应的中文释义：

2.1 代码变更类#

这一类标签直接对应代码库的修改性质，通常与 Git Commit Message 的规范（如 Conventional Commits）保持一致。

2.2 维护与杂项类#

这一类标签通常不涉及核心业务逻辑，属于后勤工作。

2.3 流程管理类#

这类标签通常由维护者使用，用于管理 Issue 的生命周期。

2.4 社区交互类#

这类标签用于引导社区参与和沟通。

📝：

在设置 Label Description 时，建议直接使用英文。

虽然团队可能全是中国人，但 GitHub 的 UI 语境是英文的，且开源项目通常面向全球。使用标准的英文描述（如上表所示）能让你的项目显得更专业、更符合国际惯例。

3. 常用 Label 的具体作用与语义详解#

给 Issue 打标签不仅仅是为了好看，更重要的是为了快速筛选和定义上下文。一个精准的标签能让维护者在 1 秒钟内判断出这是一个需要紧急修复的 Bug，还是一个可以在周末慢慢处理的代码优化。

以下是四大类标签的详细语义说明：

3.1 代码变更类#

这一类标签直接对应代码库的修改性质，通常与 Git Commit Message 的规范（如 Conventional Commits）保持一致。

🐛 bug#

• 含义：错误修复
• 场景：当软件的行为与预期不符，例如：点击按钮没反应、页面崩溃、数据计算错误。
• 作用：通常拥有较高的优先级，提示开发者需要进行“修复”工作。

✨ feat ( enhancement )#

• 含义：新功能或特性改进。
• 场景：用户请求添加一个新按钮、支持一种新语言、或者让现有的搜索功能支持模糊匹配。
• 作用：代表这是一个增量开发，通常需要经过设计和评审。

🔨 refactor#

• 含义：代码重构。
• 场景：你觉得现在的代码写得很烂（Spaghetti Code），想要重新组织目录结构、提取公共函数、或者优化类的继承关系。
• 关键点：重构不应改变软件对外的表现。既不修复 Bug 也不增加新功能，只是让代码更健康。

🚀 perf ( performance )#

• 含义：性能优化。
• 场景：页面加载太慢、内存占用过高、数据库查询延迟大。
• 作用：专门针对快和省的改进。

3.2 维护与杂项类 (Maintenance)#

这一类标签通常不涉及核心业务逻辑，属于后勤工作。

📚 docs (documentation)#

• 含义：文档变更。
• 场景：修改 README.md、编写 Wiki、更新 API 文档，或者仅仅是修正代码中的注释拼写错误。
• 作用：提示 Reviewer 这次提交不包含代码逻辑，审核起来非常快。

🎨 style#

• 含义：代码格式/风格调整。
• 场景：注意，这不是指 CSS 样式修改。 它指的是：加减空格、缩进调整、补全分号、统一变量命名风格等。
• 作用：对代码运行逻辑无影响的“美容”工作。

⚙️ chore#

• 含义：杂项/构建过程更新。
• 场景：升级 package.json 中的依赖版本、修改 .gitignore 文件、调整 Webpack/Vite 配置、配置 CI/CD 脚本。
• 作用：代表这是底层的配置变动，不影响业务代码。

3.3 流程管理类#

这一类标签用于描述 Issue 的生命周期状态。

❌ wontfix#

• 含义：不予修复/不会处理。
• 场景：用户提了一个需求，但维护者认为这超出了项目范围，或者技术上不可行，或者投入产出比太低。
• 作用：这是一个明确的拒绝信号，虽然残酷但能节省双方时间。

🔁 duplicate#

• 含义：重复的问题。
• 场景：两个用户报告了同一个 Bug，或者提了同一个功能建议。
• 作用：保留一个主 Issue，关闭其他的并标记为 duplicate，集中讨论。

⚠️ invalid#

• 含义：无效的问题。
• 场景：用户描述不清、无法复现、或者纯粹是用户自己操作失误导致的伪 Bug。

❓ question#

• 含义：咨询/提问。
• 场景：这不是代码问题，而是用户在问 “这个库怎么用？”或 “能不能支持 Windows？”
• 作用：这类 Issue 通常通过讨论解决，不需要提交代码 PR。

3.4 社区交互类#

这一类标签专门用来招揽开源贡献者

👋 good first issue#

• 含义：适合新手的第一张任务卡
• 场景：任务非常简单（比如修改一个错别字、简单替换一个函数），不需要深入了解整个项目架构就能完成。
• 作用：这是开源项目吸引新人的金字招牌。

🆘 help wanted#

• 含义：需要社区帮助。
• 场景：维护者在这个问题上卡住了，或者忙不过来，明确表示“谁有空谁来做，我接受 PR”。
• 作用：向社区发出的求救或邀请信号。

Label 的常用颜色#

请注意：颜色的选择不是为了 “好看”，而是为了 “语义化”。优秀的配色方案能让开发人员在扫视 Issue 列表时，瞬间通过颜色判断出任务的性质和紧急程度。

GitHub 的 Label 颜色不仅是装饰，它应当遵循一定的视觉语义心理学。例如，红色通常代表 “危险/紧急”，绿色代表 “新增/通过”，灰色代表 “被忽略/背景化”。

4.1 代码变更类#

使用鲜明的对比色，区分修复与新增。

4.2. 维护与杂项类#

使用柔和、中性或冷色调，避免喧宾夺主。

4.3. 流程管理类#

使用低饱和度或“终止感”的颜色，表示关闭或无效状态。

4.4. 社区交互类#

使用友好、包容度高的颜色，吸引点击与互动。