常规提交分类
Post
by Anonymous »
'''常规提交规范''' ('''CCS''') 是正式化版本控制系统中提交（版本控制）|提交分类的规范。该分类系统根据代码更改的目的（例如功能、错误修复或文档更新）来区分代码更改，以促进自动化流程，例如更改日志|更改日志生成和语义版本控制|语义版本控制。
==背景==
现代分布式软件开发严重依赖提交消息来跟踪更改。虽然早期的分类框架（例如 Swanson 于 1976 年提出的分类框架）将维护分为三种类型（完美型、适应性型和纠正型），但现代发展已转向更细粒度的分类法。
传统提交规范 (CCS) 是一种广泛采用的标准，要求提交消息遵循特定格式：
[可选范围]：
[可选主体]
[可选页脚]
强制性的
==分类类型==
对 CCS 使用的研究确定了用于对提交进行分类的十个主要类别。为了解决早期定义中发现的歧义（例如来自 Angular（Web 框架）|Angular 项目的定义），提出了以下定义以尽量减少重叠：
*“功能（feat）”：向代码库引入新功能的更改。这包括面向用户和面向开发人员的功能。
* ''Fix（修复）：'' 解决 bug 或故障的更改。
*“性能（perf）：”专门针对提高性能（例如执行速度、内存使用）而不改变行为的修改。
* ''Style（样式）：'' 在不改变含义的情况下提高代码可读性的更改（例如，格式、缩进、变量命名）。
* ''重构（refactor）：'' 重构代码以提高可维护性而不改变外部行为。此类别明确排除严格属于“风格”或“性能”的更改。
* ''文档（docs）：'' 对文档或文本文件的修改（例如评论、自述文件）。
* ''Test（测试）：'' 添加或更新测试文件。
*“持续集成 (ci)：”对 CI 配置文件和脚本的更改（例如 GitHub Actions、Travis CI）。
* ''构建（build）：'' 影响构建系统或外部依赖项（例如，Gradle、Maven）的修改。
* ''杂务（chore）：'' 不属于其他类别的杂项任务。
这些类型根据两个维度对提交进行分类：“目的”（动机，例如重构）和“对象”（更改的内容，例如测试）。在重叠的情况下，通常会优先考虑目的；例如，重构测试文件被分类为“重构”而不是“测试”。
== 采用和使用 ==
CCS 的采用在开源社区中不断增加。 2025 年的一项研究分析了 3000 多个顶级 GitHub 项目发现，自 2017 年以来正式采用 CCS 的项目数量稳步增长。 *“文件声明：”在贡献指南中明确说明约定。
*“集成自动化：”使用诸如
即使在没有正式强制执行该规范的项目中，2023 年开发人员提交的提交中也有大约 10% 自愿遵守该格式，这表明它在个人开发人员中越来越受欢迎。
==挑战==
根据 CCS 手动对提交进行分类时，开发人员面临着一些挑战。对 GitHub 和 Stack Overflow 上开发人员讨论的定性分析发现了四个主要问题： # “类型混淆：”最普遍的挑战（约占问题的 58%），开发人员不确定适用哪种类型。之间存在常见的混淆 # ''Type Aliases:'' 请求使用同义词，例如“patch”而不是“fix”。
# ''更改类型：'' 请求添加新类型（例如“安全”）或删除现有类型。
# “缺乏定义：”需要一个全面、标准化的定义列表，因为官方规范通常遵循 Angular 的指南，而一些开发人员认为这些指南含糊不清。
==自动分类==
鉴于十个 CCS 类别的复杂性和粒度，我们探索了自动分类来帮助开发人员。 虽然使用 BERT（语言模型）|BERT 的传统方法在三类分类（自适应、校正、完美）方面取得了成功，但它们在 CCS 的更精细区分方面遇到了困难。
最近使用大型语言模型|大型语言模型（LLM）的方法，特别是像 Llama（语言模型）|CodeLlama 这样的微调模型，已经证明了卓越的性能。经过微调的 CodeLlama 模型获得了大约 76% 的宏观 F1 分数，在将提交正确分类为 10 种 CCS 类型方面优于 BERT 和 GPT-4。
==来源==
*
软件工程
版本控制
Mobile version