Abstract

协作软件开发中的一个关键问题是开发人员之间的沟通。通信的一种方式是 Commit Message，开发人员在其中描述他们在存储库中所做的更改。因此，commit message可以作为一种“审计跟踪”，开发人员可以通过它来理解项目的源代码是如何变化的，以及原因。因此，commit message的质量会影响开发人员之间通信的有效性。由于开发人员编写提交信息缺乏时间和动力，因此提交信息的质量往往很差。已经提出了几种自动的方法来生成commit message。然而，这些数据都是基于未经管理的数据集，其中包括相当大比例的措辞不当的commit message。在这个多方法研究中，我们首先定义什么构成了“好的”commit message，然后使用来自5 个高度活跃的开源项目的近 1600 条消息的样本来确定commit message缺乏信息的比例。我们发现，平均约 44%的消息可以得到改善，这表明，当使用这些数据训练commit message生成器时，使用未经管理的数据集可能是一个主要威胁。我们还观察到，以前的工作没有考虑到commit message的语义，而且令人惊讶的是，关于编写良好的commit message的指导也很少。为此，我们开发了一个基于commit message表达式中的循环模式的分类法。最后，我们研究了是否可以自动识别”好的”commit message；这种自动化可以促使开发人员编写更好的commit message。

1 INTRODUCTION

协作软件开发是一种固有的社会活动，通常通过版本控制系统（VCS），如 Git [75, 82]来促进。VCS 维护代码更改的记录，并管理对开发对象[82]的同时访问。每个提交都应该包含对源代码（和其他存储的工件）的更改，并包含一条解释所做了哪些更改以及为什么要进行[13, 49]的消息。图 1 显示了来自 Spring-启动项目[64]的 commit message 的一个示例。需要一个 well-written message 来将更改的上下文传达给协作者，这使他们能够审查更改并理解其影响[2, 69]。对于长期的项目，比如 Linux 内核，commit message 可能是唯一的信息来源，以便未来的开发人员了解在原始开发人员离开项目[68]时做了哪些更改以及为什么要做这些更改。

软件开发越来越多地在分布式环境中进行，其中涉及到来自许多不同文化和背景的开发人员。此外，在过去的 20 年里，对开源软件（OSS）项目的商业参与急剧增加[77-79, 81]，导致 OSS 项目的开发人员队伍进一步多样化，这些项目已经成为许多软件组织的重要组成部分。这反过来又可能会进一步多样化个人开发人员和组织的提交信息质量可能表现出不同的开发文化和习惯。

一些研究人员发现，由于缺乏动机或时间[26, 44, 45, 47]，存储库中 commit message 的质量会有所不同。例如，以前的研究观察到，在超过 23, 000 个 OSS 项目中，14%的 commit message 是完全空的，66%的消息只包含几个单词，只有 10%的提交有包含“正常的”描述性英语句子[26]的消息。Chahal 和 Saini [14]提出了一个语法模型来计算 commit message 的质量。但是，该模型只能通过对“规则”的评价来评估句法层次上的质量，例如“主题行的第一个字符应该大写”；这个模型没有考虑 commit message 内容的语义。此外，开发人员可能不知道应该编写什么类型的信息来生成良好的 commit message [68]。开发者社区热衷于帮助他们的贡献者理解如何编写一个好的 commit message，这样指导方针就证明了：“commit message 应该描述我们的提交对代码的行为做了什么更改，而不是代码中发生了什么变化”[51]。

为了帮助开发人员编写commit message（解决潜在的动机和时间的缺乏问题），已经提出了几种工具，可以自动生成commit message为[13, 18, 45]。像 DeltaDoc [13]和 ChangeScribe [18]这样的工具可以根据提交中包含的更改生成详细的消息，这些更改主要可以回答所更改的内容。但是，生成的消息并不能揭示为什么需要进行更改。受之前的观察到的commit message遵循某些模式[49]的启发，最近的方法[38, 39, 45]从之前的更改及其关联的commit message生成commit message，这可能包含任何代码更改的基本原理。对于这些方法，生成的commit message的质量依赖于训练数据中发生类似代码变化的消息。一个主要的问题是，在为自动生成器的训练数据集中使用的 OSS 项目中，commit message的质量可能会有很大的差异。因此，如果不在训练数据集中过滤掉低质量的commit message，这些“低质量”commit message会带来重大威胁。此外，当生成的消息与测试数据集中的低质量消息相同或相似时，自动工具可能会人为地产生高精度。不幸的是，迄今为止提出的许多模型都是在commit message的数据集上进行训练和评估的，它们只是删除了琐碎的消息，而不注意这些消息的内容质量。

这种情况使一些重要的开放性问题悬而未决。

首先，（RQ1）存在多少不佳的 commit message？据我们所知，以前的工作没有定义或分析什么是“好的” commit message，然后分析 commit message 以评估消息质量的变化程度。
第二，（RQ2） Good commit message 具体是什么样的，这些编写良好的消息是如何表达的？正如我们所观察到的，目前的技术状态不考虑消息的语义，只考虑消息的语法
最后，未来可以帮助开发人员编写好的commit message的工具应该能够识别编写的消息是否“好”。例如，可以在开发人员尝试提交时实时提示他们的工具可能有助于提高commit message的质量。这些工具对于研究人员构建commit message生成的高质量数据集也非常有用。因此，我们的第三个研究问题是（RQ3）：是否可以自动识别高质量的commit message？

为了回答这些问题，我们进行了一项多方法研究。我们首先研究并分析了来自五个主要OSS项目的大约1600条commit message。我们定义了一个“好的”commit message，解释了发生了什么变化以及原因。我们发现，大约44%的提交邮件缺少“为什么”或“什么”信息。这突出了基于包含低质量commit message的未过滤训练数据集生成消息的风险。其次，我们定性分析了252条带有“好”消息标签的消息，以识别表达特征。第三，我们构建了一个基于Bi-LSTM的模型，以自动识别编写良好的消息并实现良好的性能。

本文对有关理解和识别高质量commit message的文献做出了一些实践和理论贡献。具体地说，

我们提出了一套标准来识别写好的信息；
证明相当大比例的commit message缺乏基本信息，从而强调这种质量差异需要采取措施加以缓解；
提出commit message表达式的分类；以及
建立一个自动分类器来识别写得好的消息。

在本文的剩余部分，我们在第 2 节中回顾了相关工作，在第 3 节中概述了我们的多方法研究方法，并在第 4 节中介绍了我们的研究结果。我们在第 5 节中讨论了对研究和实践的影响。我们在在第 6 节中对我们报告的结果的有效性提出了威胁，在第 7 节中总结了论文。

我们讨论了以前的文献，这些文献侧重于理解和利用commit message以及如何自动生成commit message。在解决几个软件工程挑战时，commit message是一个关键资源。一系列研究集中于通过手动或自动使用commit message来帮助维护，将代码更改分类为不同类型[25，49，54]。例如，Mockus 和 Votta[49]确定了三种类型的提交：适应性、纠正性和完善性，与 Swanson 的维护活动类型一致[67]。基于所提出的提交类型，已经提出了许多分类模型，commit message起着重要作用[25，42，74]。

第二波研究集中在通过分析commit message来度量代码更改的质量。例如，Agrawal 等[2]研究了五个项目中提交质量的演变，通过测量 (尤其是) 独特commit message的数量，发现提交质量随着时间的推移而下降。Santos 等[58]研究了提交中“异常消息”和代码质量之间的关系，发现异常消息与构建失败相关，表明这些消息可以作为一个警告信号。

一些学者提出了自动生成消息的方法。其中一些是基于规则的，或者使用预定义的模板[13, 18, 43, 63]。例如，Buse 和 Weimer [13]使用符号执行生成代码更改版本之间的路径谓词，然后填充预定义模板和应用摘要转换生成代码更改的commit message。这些基于模板生成的commit message有两个重要的局限性: (1) 缺乏灵活性，(2) 它们不能传达提交更改的意图，这种意图只存在于开发人员的头脑中，直到它被编写出来。最近的研究依赖于先进的技术，如信息检索和深度学习[35, 38, 44-46, 50, 72]来自动生成提交信息。它们往往依赖于重用类似代码更改的消息。例如，Huang 等[36]计算了两个版本之间变化的代码片段的语法、语义、前语法和前语义相似性，以发现相似的代码变化并重用它们的消息。虽然具体的模型在技术上有所不同，但是它们的一个共同特征是将之前的commit message作为关键输入。对于这些基于信息检索和深度学习的工具来说，手写提交信息的质量很难保证，这可能会威胁到这些工具的有效性。一些研究调查了commit message的内容，但主要集中在特定方面。例如，Alomar 等人研究了开发人员如何在commit message中记录他们的重构活动，并发现开发人员倾向于明确提到某些质量属性和代码味道的改进[4]。Chahal 和 Saini [14]构建了一个模型，该模型可以通过计算 11 个语法度量来判断commit message的质量。其他开放源码软件开发活动中的文本内容已经被研究过，比如在提交补丁时记录什么/如何记录，以及缺陷报告中需要什么信息[83]。我们对好的commit message的分布和表达类别以及它们与维护活动的关系的研究结果可以补充先前对什么是好的commit message以及如何编写好的commit message的理解。此外，我们提出了一个好的消息识别工具，可以用来促使开发人员编写更好的commit message，并为自动生成commit message的任务构建高质量的数据集。

3 STUDY DESIGN

为了解决第一节中介绍的三个研究问题，我们进行了多方法研究。

为了解决 RQ1 问题，我们编译了一个提交数据集，并根据我们对“好的”commit message的定义手动对消息进行分类。第 3.1 节描述了样本选择、数据收集和数据处理步骤。第 3.2 节描述了我们对commit message进行分类的方法。
为了解决 RQ2 问题，我们开发了一个分类法，描述commit message如何传达“什么”和“为什么”信息 (参见第 3.3 节)。
最后，为了解决 RQ3 问题，我们提出了一个能够自动识别这些写得很好的消息的模型 (参见第 3.4 节)。图 2 给出了这种方法的概述。附录提供了一个复制包[71]。

3 .1 Data Collection and Preprocessing

为了确保我们的样本包含足够高质量的提交消息，我们选择了具有高度协作的活跃和受欢迎的项目。我们假设这些项目至少有一些非常重要的提交消息。考虑到不同编程语言对软件开发的影响[11]，在这项研究中，我们重点关注用 Java 编写的项目，Java 是 GitHub 中最流行的编程语言之一[30]，在行业中广泛使用。我们选择了 GitHub 中按“星级”排序的前 100 个 Java 项目。在审查这些项目时，我们优先考虑了以前关注自动生成提交消息的研究主题的项目。通过解决这些研究的一些局限性，我们试图在未来改进以前专注于提交消息生成的研究中提供本研究的结果。

因此，我们为这项研究选择了五个 OSS 项目，如表 1 所示。Springboot[64]帮助开发人员以较少的配置创建和运行基于 Spring 的应用程序。ApacheDubbo[9]是一个高性能的微服务开发框架。Okhttp[65]是一个 HTTP 客户端。Junit4 [70]提供了编写可重复单元测试的能力。Retrofit[66]是适用于 Android 和 Java 的类型安全 HTTP 客户端。五个被广泛调查的[6、16、24、43、74、76]项目中的每一个都有超过 150 名贡献者、超过 8000 的 star 和数千名提交者，这表明这些项目中存在着积极的合作。

我们使用 GitHub 的 REST API[31]收集了截至 2021 2 月的五个项目的所有提交。在数据收集中，我们只考虑了使用英语编写消息的提交。这导致了一个包含 41886 个提交的数据集（见表 1）。我们消除了基于固定模式的工具（bot 消息）自动生成的提交消息，因为这项研究侧重于手动编写的消息。基于现有工作[7，22，23，27]所识别的模式，可以容易地识别和过滤这些机器人消息。表 2 显示了我们数据集中排除的几个 bot 消息模式（忽略案例）。在这个数据清理步骤之后，剩下 29348 条提交消息。

3.2 Identifying Well-Written Messages

定义好的 commit message

众所周知，提交消息的质量参差不齐[26, 45, 47] ，但是高质量消息的公认标准至今仍然缺乏。在调查写得好的信息的特点之前，我们通过对学术论文和开发者论坛的调查来构建标准来识别它们，并且与有经验的开放源码软件开发者一起验证这些标准，如下所述:

为了获得提交信息的科学视角，我们确定并回顾了 46 项相关研究 (全文列于我们的在线附录[71]) ，主要关注提交信息的期望以及是否存在好信息的标准。
为了获得对提交消息的务实且面向实践的观点，我们使用了 Google 的搜索引擎和短语“好的提交消息”在按相关性排序的前 50 名结果中，我们手动选择和研究了来自 OSS 社区或 OSS 开发人员的在线记录 (及其参考文献)(整套链接包括在附录中[71])。
此外，我们还征求了 30 位经验丰富的 OSS 开发人员的意见，以收集他们对什么构成好的信息的看法; 我们在这里定义“经验丰富”为那些为所研究的项目贡献了 10 个commit以上的开发人员。

通过对所选记录的定性分析，我们发现提交消息最常见的期望是总结此提交中的更改（记为“什么”）并描述更改的原因（记为”为什么“）。受调查的开发人员在提交消息的内容上表现出高度一致性：大约 93%的开发人员认为提交消息应该总结所做的更改，并描述为什么需要这些更改。也就是说，提交消息应该同时包含“什么”和“为什么”信息，以帮助合作者理解更改，而不仅仅是总结更改或描述更改的原因。

因此，我们基于这样一个假设进行了这项研究：即一个好的提交消息应该包含一个描述变更动机的理由（即Why）和一个变更摘要（即 What）。根据两个关键元素“Why”和“What”是否包含在内，我们将数据集中的提交消息分为四种类型：“Why和What”（包含两者）、“没有Why”（只有What信息，但没有Why）；“没有What”（只有Why，但没有What）；以及“既不是Why也不是What”。

我们注意到，某些变化的原因信息可能是常识。例如，提交消息“fix typ a->an”省略了提交的原因，这可以很容易地推断为“提高可读性”。从减少开发人员工作量的角度来看，我们没有将这些提交消息归类为“No Why”，因为理由很简单。类似地，一些 what 信息可以很容易地从代码变更中推断出来，我们采取了与“为什么”相同的方法。在 4.2.1 和 4.2.2 节中可以找到更多关于常识“为什么”和“易于推断”类别的细节。

此外，我们发现一些提交通过提供 Issue 或 PR 的链接来表达为什么信息，其中通常包括详细的动机和对变更的讨论[8，82]。然而，这种方法是有争议的：一个学派认为，这些关联的资源提供了一种方便的方式，可以提供详细的细节，阐明变革的理由[60，68]。另一种观点认为，这种链接会带来风险，因为它们可能会过时，导致它们所指向的信息丢失，从而导致难以理解的提交消息[41]。在这项研究中，我们采用了前一种观点，并将提交消息中的问题报告和拉取请求的链接视为提供“为什么”信息的一种方式

为了研究所选项目中四种消息类型的分布(表 1) ，我们对五个项目的提交数据使用了聚类随机抽样技术[5] ，并选择了由 339 名开发人员提交的 1, 649 条提交消息(置信度: 95% ，误差幅度: 5%)。平均而言，每个开发人员在我们的数据集中提交了大约 5 次提交。本研究的前两位作者分别标记了提交消息，并将其分为四种消息类型。在标记过程中，我们确定并消除了 52 个非原子提交，其中提交了多个更改，在单个提交中进行多种更改被认为是糟糕的做法，因为可能会降低可维护性。

在标记了这些信息 (1, 649 减去被删除的 52) 之后，两位作者之间的卡伯值系数为 0.91。至于标签不同的信息，我们召开了几次会议来解决 66 个 (大约 4.1%) 分歧。如果前两个提交人未能就类型达成协议，则由第三个提交人担任仲裁员。

此外，我们通过与开放源码软件贡献者进行调查来验证标记的结果。具体来说，我们从按星数排序的前100个 Java 项目中选择了958个有经验的贡献者(即那些贡献超过10次提交的人) ，并向他们发送了一份问卷(见附录[71])来征求他们的意见。我们收到30个有效回复(回复率为3.1%)。在计算了开发人员标记的120个结果(每个受访者标记为4个提交消息)后，我们发现有102个结果与我们的结果标记一致。这表明，该数据集的准确率达到近85% 。

3.3 Characterizing Well-Written Messages

在第二阶段，我们试图确定写得好的信息的特征（见第 3.2 节）。我们手动采样了 271 条（置信度：95%，误差幅度：5%）带有标签类型“为什么和什么”的提交消息，即同时包含为什么和什么信息的消息，因此没有遗漏重要信息。在 271 个提交中，我们删除了 19 个仅使用拉取请求或发布报告链接来表达“为什么”的提交。对于剩余的 252 条消息，我们根据以下过程使用主题分析[20]来描述开发人员如何在提交消息中表达“为什么”和“什么”信息。（1）我们首先阅读并分析了所有提交消息，以了解开发人员如何描述代码更改和动机，并确定了表达“为什么”和“什么”的短语。（2）我们仔细阅读整个提交消息和相关短语，以生成初始代码并以系统的方式组织它们。（3）在完成初始代码的生成之后，我们聚合了具有类似含义的代码，并确定了表示该集群的初始主题。在这一步之后，所有的代码都被划分为一个初始主题，这有助于识别出描述“为什么”和“什么”的任何紧急模式。（4）然后，我们回顾了最初的一组主题，以确定合并类似主题的机会。通过澄清每个主题的本质，类似的主题被合并为一个新的主题，或者将一个主题作为子主题。（5）在最后一步中，我们定义了最后一组主题。为了减少研究人员的偏见，前两位作者独立执行了上述步骤（1）至（4）[57]。之后，举行了一系列会议，以解决冲突并分配最终主题（步骤5）。

在对 252 条提交消息的主题分析中，我们发现开发人员在消息中描述“为什么”和“什么”的方式在不同类型的维护活动中往往有所不同。因此，我们还对提交类型进行了分类，以研究消息表达类别与维护活动之间的关系。先前的文献提供了各种代码更改分类[49，56，67，73]，但对于提交所指的不同类型的分类，没有达成共识。因此，在专门的文献回顾之后，我们采用了 Mockus 和 Votta[49]的广泛使用的定义，用于三种提交类型：（1）纠正性更改解决了处理、性能和实现失败；（2）自适应变化表示数据环境或处理环境中的变化。例如，实现一个新功能；（3）完善性改变，其重点是改善非功能属性，如效率、性能、清理等。

然后，我们通过演绎主题分析[53]确定了提交类型，这可以将数据与现有研究的主题相匹配。更具体地说，前两位作者独立地将源自Mockus和Votta[49]的理论命题作为出发点，并将其应用于252条提交消息。我们在两个编码器之间获得了高水平的一致性（Cohen’s kappa系数=0.92）。两位编码员讨论并解决了任何分歧。

3.4 Automatic Identification

自动识别

在第三阶段，我们试图开发一种能够自动识别写得很好的消息的解决方案。当我们将高质量提交消息定义为同时包含 Why 和 What 信息的消息时，我们首先设计了两个分类器，它们可以分别自动识别消息是否包含 Why (标记为 C-Why，C 意味着“分类器”) 和 What (标记为 C-What)。通过指示两个关键元素（为什么和什么）中的哪一个缺失，训练两个独立的分类器可以为开发人员提供更细粒度的反馈。然后，我们选择并组合了性能最佳的两个分类器，以自动识别包含 Why 和 What (标记为 C-Good) 的良好编写的消息。

3.4.1 数据准备

我们使用第 3.2 节中标记的提交消息来训练和测试三个分类器。提交消息通常包含几个非“自然语言”的令牌，例如拉取请求的链接。由于它们的完整语义高度特定于提交的内容（我们在本文中没有考虑到这一点），我们将这些标记替换为指示信息类型的占位符，以确保模型不受此类琐碎提交内容的影响。具体来说，我们识别并替换了以下非自然语言的标记：

我们将消息中的任何 url 替换为<X url> ，其中“X”表示 url 的类型，即“pr”（表示拉请求链接）、“issue”（表示问题报告的链接）和“other”。
我们用“ < X name >”替换消息中的代码元素，其中“ X”指代代码元素的类型，如方法和文件。这些代码元素是通过将消息与相应的代码更改进行比较来识别的。
通过用 < enter >替换换行符，我们保留了提交消息的段落信息。

3.4.2 识别

原始数据集很可能是不平衡的，即包含“为什么”(或“什么”) 的消息数量大于不包含此信息的消息数量。然而，不平衡的数据集会导致机器学习 (ML) 模型只关注主要类别，而忽视了我们在本文中更关注的其他次要类别。

基于机器学习的分类器通常采用过采样的方法来解决数据不平衡问题，以获得更好的分类性能。为此，我们尝试了三种广泛使用的过采样技术，包括随机取样替代[37] ，合成少数过采样技术 (SMOTE)[15]和自适应合成 (ADASYN)[33] ，在训练分类器之前准备数据，并选择在每个分类器中产生最高准确性的技术。

接下来，对输入文本消息进行向量化。矢量化方法，即变压器的双向编码器表示 (BERT)[21] ，已被证明在包括文本分类在内的自然语言处理任务中表现出良好的性能[1, 29]。我们使用 BERT 嵌入标记化和填充的提交消息，并将每个消息转换为一个数值向量。已经提出了大量的技术来解决自动分类任务[48]。我们考虑了对提交消息进行分类的最广泛使用的技术，包括长短期存储器（LSTM）[34]、双向长短期内存（Bi-LSTM）[61]、多层感知器（MLP）[52]、Logistic 回归[48]、随机森林[12]、K 近邻（KNN）[19]、梯度提升机[28]和决策树[55]。我们评估了他们在分类任务中的表现，并选择了表现最好的方法。

4 RESULTS

现在介绍我们的研究结果，解决了第 1 节中概述的三个研究问题。第 4.1 节介绍了不同类型提交消息的分布。第 4.2 节介绍了一个编写良好的消息分类，包括开发人员用来描述“什么”和“为什么”信息的表达式类别。第4.3节介绍了我们的写好消息自动分类器的性能结果。为了便于追溯，我们提供报价消息，并在数据库中提供标识符[71]。

4.1 Quality Distribution of Commit Messages

我们根据 1597 个提交（从五个 OSS 项目中抽取）的消息是否包含“为什么”和“什么”信息，将其手动分类为四种类型（见第 3.2 节）。我们计算了这四种提交消息在五个 OSS 项目中的分布。图 3 显示了结果。我们可以看到，四个项目（Retrofit 除外）中的主要类型是写得很好的消息，即这些消息包含“为什么”和“什么”信息。这五个项目中这种消息类型的比率从约 42%到约 82%不等，平均比率约为 56%，这表明约 44%的提交消息存在质量问题。这反过来表明，使用包含如此大部分的数据集训练的生成提交消息的任何自动化方法都可能受到损害，因为生成的消息可能是从这些不完整的消息中学习到的。虽然我们的五个项目样本显然不能代表 GitHub 上的大型 Java 项目，但这一发现确实突出了现有工具的有效性方面的一个潜在问题。

至于三种有问题的信息类型，“No Why”（仅包含 What 信息）所占比例最大，平均为 28%，大约是仅包含 Why 信息的信息的比例（平均为 12%）的两倍。这可能表明，编写代码更改的原因比描述更改的内容更具挑战性。此外，“No Why”和“No What”的比例大不相同，这可能解释了为什么为代码更改生成 Why 信息比生成 What 信息更难，这是先前的研究所证实的[44–46]。既不包含“为什么”也不包含“什么”的消息类型所占比例最小，从约 1%到约 8%不等。为了进一步调查“既不是为什么也不是什么”类型到底包含什么信息，我们手动分析了这类 65 条消息。按照第 3.3 节所述的主题分析步骤[20]，我们确定了五个类别，每个类别都具有独特的特征：

单字消息：仅包含一个几乎不表达任何信息的令牌。“Merge”、“Polish”和“＜file name＞”是标记数据中的典型示例。
以提交为中心的消息：只表达提交的事实。例如，“Loader changes”。很明显，这是一次提交，但不可能知道这些更改是什么，以及为什么要进行这些更改。
以范围为中心的消息：只解释更改的范围。此类信息的典型信息包括“测试中的微小变化”。大多数此类信息包含限定词，如“主要”和“次要”，无法表达其他信息。
冗余消息：描述容易从代码差异中推断的内容。例如，“ Add < file name >”，“ Delete < file name >”。即使不阅读此消息，也可以轻松确定添加或删除文件的事实。
无关信息：描述与变化无关的内容。像“Kent&Erich 在 Merlin 吞补丁”这样的消息是用来提交一个非空消息的，它根本不传递任何信息。

上述分析清楚地表明，有相当一部分的提交消息是有问题的，也就是说，它们不包含重要的信息。正如我们在第 2 节中所讨论的，已经使用提交消息作为数据集来训练和评估了几个消息生成器，而没有过滤出次优消息。因此，由于使用次优数据，引入了一个主要威胁。第四种类型，“既不是为什么也不是什么”，可能很容易识别和删除，但这种类型只占有限的比例。换句话说，过滤这种类型的消息不能充分解决威胁，需要更强大的自动识别好消息。

RQ1 总结: 在所研究的五个 OSS 项目中，提交消息的质量各不相同，平均约有 44% 的消息需要改进。此外，我们确定了五类既不包含“为什么”也不包含“什么”的消息

4.2 A Taxonomy of Commit Messages

commit Messages 分类

现在我们转向 RQ2，它试图阐明是什么使一个编写良好的提交消息成为可能。我们确定了各种类型的基本原理 (“为什么”) 以及内容 (“什么”) ，并分析了这些类别与 Mockus 和 Votta 类型学之间的关系[49]。请注意，同一消息中可能存在多个类别的“为什么”(或“什么”)。具体来说，我们在 4.2.1 节和 4.2.2 节中介绍了这些类别，并在 4.2.3 节中介绍了这些类别的流行情况。我们在我们的在线附录[71]中总结了“为什么”和“什么”类别的详细代码和统计数据。

4.2.1 Why 分类

通过分析开发人员表达变更理由的各种方式（即，为什么），我们发现开发人员倾向于直接或间接地表达这一点，或者当变更的原因是常识或者可以由变更本身解释时，有时根本不表达。使用第 3.3 节中概述的程序，我们确定了五个主要类别和 18 个子类别。我们通过以下示例介绍这些（子）类别，包括 252 条分析的提交消息中的计数和百分比（用括号表示）。

描述问题。这一类别直接阐述了代码更改的动机；它主要关注当前代码实现中的一个问题。开发人员通过描述这些问题和发生这些问题的具体场景来解释他们进行更改的动机。这使得其他贡献者更容易理解提交的上下文。我们确定了三个子类别：
说明要求。第二类，说明需求，描述了导致此提交的需求的来源。这些要求包括软件开发和解决软件维护过程中的问题。我们确定了三个子类别：
描述目标。第三类基本原理提供了变更的目的，例如未来预防缺陷或优化功能或性能。我们确定了两类目标：
暗示必要性。与前三个类别中的提交消息不同，“隐含必要性”类别中的消息仅间接描述更改的需要。开发人员间接地描述了使用属于以下子类别的消息进行更改的必要性:
缺少Why。此类别包括不提供理由的提交消息，例如，当它是常识或易于推断时。在这种情况下，无需提供理由。其中包括以下六个子类别：

4.2.2 What 分类

我们确定了四个类别来表示更改，即如何在提交消息中表示“ What”。我们通过以下示例介绍这些类别，包括它们在 252 个经过分析的提交消息中的计数和百分比 (在括号中指出)。

汇总代码对象更改。第一类表示总结更改的提交消息；有效地总结了差异。我们确定了以下子类别：
描述实施原理。此类别表示提交消息，描述支持更改的技术原则。实现原理显示了代码正确执行的过程。例如，“SslContext Builder 使用 InetAddress. getByName（null）[…]在 Android 上，null 返回 IPv6 环回，其名称为’ip6 localhost’”[ #S251 ]。只有六次提交（252 次，2.4%）属于这一类别。
说明功能。此类别中的提交消息从功能角度总结和解释代码更改。与描述代码中的特定更改不同，这些消息更关注功能更改。这些消息通过描述这些变化所引入的任何新行为来通知其他贡献者发生了什么变化。例如，“重命名首选映射器属性，使其明确仅适用于 JSON”[ #S169 ]。这一类别很常见，在 252 个分析的提交中，有 65 个通过说明功能来表达更改的内容。
缺少 What。此类别指的是没有任何更改内容说明的提交消息。通常，任何此类变化都很小且简单，很容易推断出来。我们在 19 次提交中发现了这一类别（占 7.5%）。常见的例子有排印错误的纠正、源代码对象的重命名以及添加和删除空格。

4.2.3 将维护维度链接到提交消息。

如第 2 节所述，根据 Mockus 和 Votta 的定义，维护活动的性质因类型而异[49]。不同类型的维护活动（根据 Mockus 和 Votta 的类型[49]）往往采用不同的方式来描述变化。我们分析了为什么和什么在不同开发活动中的表达类别的分布（见表 3）。值得注意的是，一些开发人员在描述“为什么”或“什么”时同时使用多个（但不超过两个）表达式类别，而这些消息只占很小的比例，即在 252 条消息中不超过 9%。

执行修正性更改以修复现有代码库中的缺陷。如表 3 所示，描述问题是解释纠正更改原因的最常见表达类别，最高比例为 45.7%。开发人员还通过将描述问题与描述目标（0.8%）和隐含必要性（2.6%）相结合来表达代码更改的基本原理。同样，代码对象更改摘要是在提交消息中描述该维护类型的最常见类别，占 58.6%。
对于适应性变更，开发人员通常通过间接暗示变更的必要性（类别暗示必要性）来描述原因，最高比例为 39.7%，其次是说明需求类别，阐明了支持变更的需求。一个可能的原因可能是，处理或数据环境中的新特性或更改通常表明在第一次提交时需要进行更改。然而，大多数新特性的实现需要多次更改，开发人员可以通过描述与特性的关系或更改以前接受的内容来解释更改的动机。另一个原因可能是对支持添加新功能的更改的改进或好处的描述。
开发人员为提高代码可读性和质量所做的完美更改通常只涉及文本文件、注释或测试。这些变化的动机往往是常识，所以为什么信息在信息中经常被省略（类别 Missing Why），比例为 34.2%。对于其他非功能性属性，开发人员倾向于使用“隐含必要性”和“说明需求类别”。

我们可以看到，最常见的表达“为什么”的方式因维护活动的类型而异，即“描述纠正性变更的问题”、“暗示适应性变更的必要性”和“遗漏完美变更的原因”。然而，开发人员在描述更改时倾向于直接总结代码更改。除了完善的维护活动外，从功能变更的角度总结变更也是开发人员常用的方法。可能的原因是，非功能属性的改进没有反映在软件提供的功能中。缺少 What 类别对于所有三种维护活动都不常见

RQ2 的总结：我们确定了“为什么”的五个表达类别和“什么”的四个表达类别。此外，我们还发现，开发人员在为不同的活动编写提交消息时具有不同的表达式偏好。这些结果可以帮助开发人员编写一个好的提交消息。

4.3 Automatically Classifying Good Messages

10 折验证，方法比较

Positive 是缺失 Why、What、Good messages Negative 是有 Why、What、Bad Messages

与平均只有56%的良好提交消息的未过滤数据集相比，我们的分类器可以自动识别和构建一个更高质量的提交消息数据集。

RQ3 的总结: 我们提出了三种基于 Bi-LSTM 的分类模型来自动识别提交消息是否写得很好，以及提交消息是否包含“为什么”或“什么”它们在我们的数据集中都表现良好，可以重用。

5 IMPLICATIONS

意义

提交消息对于促进开发人员之间的协调和沟通至关重要，因此理解什么是好的消息以及如何编写它们是很重要的。我们将讨论对开发人员和研究人员的影响。

5 .1 对开发人员的影响。

我们对“为什么”和“什么”信息表达方式的分析，使开发人员能够理解什么构成了良好的提交消息。同时，将维护活动链接到消息表达式类别的结果可以促使开发人员编写更好的提交消息。例如，在执行纠正任务时，开发人员最初可以选择最常见的表达式类别 (适用于许多场景) ，即描述问题; 这不仅可以改善提交消息，还可以激励开发人员更多地了解表达为什么需要更改的不同方式。更具体地说，子类别描述错误场景可以激励开发人员描述 bug 复制步骤和更改的背景，同时，开发人员可以选择最通用的方式提交 messages，有利于统一 message 的风格。

我们还为开发人员设计了两个自动工具，以检查正在写入的提交消息是否符合一个好的工具，即同时包含为什么和什么。在这些工具的帮助下，开发人员可以知道他/她的提交消息中缺少了什么，并相应地进行补充

5.2 对研究人员的启示

我们的研究表明，相当比例的提交消息质量较差 (在五个流行的 OSS 项目中平均为 44%) ，这表明开发人员共享知识的这种重要模式没有得到最佳使用。虽然这对任何项目的长期可维护性都有影响，但我们也观察到，自动生成提交消息的方法是用未经管理的数据进行训练的，例如，带有提交消息的数据集没有基于质量进行过滤。反过来，这样的模型也会生成低质量的提交消息，从而加剧了写得不好的提交消息的问题。

然而，对于研究人员来说，手动管理好的提交消息是非常耗时的。我们提出了一个自动分类器(即 C-Good) ，它能够很好地识别好的提交消息(精度: 81.6%)。这个分类器有可能帮助研究人员从存储在 GitHub 和其他 VCS 中的大量历史数据构建一个高质量提交消息的大型数据集。在未来，有必要构建一个标准的提交消息数据集，以方便不同生成方法之间的比较，提高生成消息的质量。

6 THREATS TO VALIDITY

方法的缺陷

在构建数据集时，我们删除了已知 bot 生成的提交消息[7, 22, 23, 27]。这可能是因为新的机器人正变得越来越先进，并产生更多类似人类的消息，这表明一种威胁，即经过过滤的数据可能仍然包含一些非人类书写的消息。今后的工作应该考虑新机器人的发展，因为它们可能需要更仔细的数据过滤。值得注意的是，在 1, 649 条手工分析的消息中，我们没有发现任何新的 bot 模式，这表明我们的定性分析结果没有受到影响。

手动标记提交消息会对有效性构成主观威胁。为了尽量减少这种威胁，两位作者分别给消息贴上标签，并介绍一位经验丰富的质性研究同事通过几次讨论达成一致意见。一致性水平 (0.91) 很高，表明可靠性水平很高。其中一些标签信息随后得到了有经验的开放源码软件贡献者的确认。此外，手动分析的消息来自 339 名开发人员。这意味着多个提交消息可能来自同一个作者，这对限制消息分类的多样性构成了威胁。未来的一项工作可以扩展这种分析，包括更多的项目 (并且使用 Java 以外的其他语言编写) ，以验证并且如果需要的话，丰富本研究中报告的提交消息的分类。

另一个威胁是数据集 (总共 1, 597 条消息) 对于训练分类器来说不够大。该数据集是从五个 OSS 项目中随机抽取的，其有限的规模是由于手动标记和分析提交消息所涉及的复杂性。为了减少这种威胁，我们使用了十倍的交叉验证程序来从数据集中获得尽可能多的有效信息 (九倍) ，并使用不同测试数据集的平均性能来提高模型的泛化能力[59]。然而，随着时间的推移，开发人员可能会写出更好的消息。十倍交叉验证，即随机分成十个子集，没有考虑到时间对开发者写信息经验的影响。这是未来工作进一步增加这些结果的严谨性的一个潜在方面。

当自动对提交消息进行分类时，其他因素可能与提交消息的质量有关。例如，Chahal 和 Saini [14]提出了 11 个与格式相关的度量标准来衡量提交消息的语法质量。我们的分类器只使用消息的文本内容作为训练的输入。为了减轻这种威胁，我们在预处理期间用统一的令牌替换了那些与格式相关的元素 (参见第 3.4 节) ，比如使用“ < enter >”表示线路刹车。这种预处理确保在对提交消息进行分类时考虑语法特性。

对外部效度的威胁考虑到我们研究结果的普遍性。我们分析的数据集是从 5 个在 gitHub 上用 Java 实现的流行项目中收集的，因此对外部效度造成了威胁。我们的发现可能无法推广到其他项目，无论它们是开放源代码还是封闭源代码，或者使用其他语言的项目。很有可能使用其他编程语言的开发人员具有不同的消息编写模式，而这些模式在本文的范围内还没有被研究过。未来的研究可以调查更多不同的项目，以便更深入地了解什么构成了一个好的提交信息。尽管有这些限制，我们提出的自动分类工具可以很容易地适应其他项目与其他语言，只需替换数据集。

7 CONCLUSION

提交消息在协作软件开发和进化中发挥着重要作用。尽管如此，OSS 项目中相当大比例的低质量消息反映了开发人员在编写提交消息时所面临的困难，并威胁到现有的自动提交消息生成工具的有效性。我们的研究探讨了这些编写良好的消息的分布和表达模式，将消息表达类别与不同的维护活动联系起来，并构建了几种良好提交消息的自动识别模型。我们的研究结果可以帮助开发人员编写好的提交信息，并帮助研究人员在自动生成消息之前构建高质量的数据集。