Generating Commit Messages from Git Diffs
提交消息帮助开发人员理解不断发展的代码库。然而，开发人员并不总是正确地记录代码更改。自动生成提交消息将减轻开发人员的负担。最近，许多不同的工作已经证明了使用神经机器翻译的方法来生成提交消息的可行性。这项工作的目的是再现在这一领域的一个突出的研究论文，以及试图通过提出一种新的预处理技术来改善他们的结果。参考神经机器翻译模型的复制能够在相同的数据集上实现稍微好一点的结果。然而，当应用更严格的预处理时，性能显著下降。这表明了当前提交消息生成模型的固有缺陷，这些模型通过记忆某些结构来执行。未来的研究方向可能包括改进diff嵌入和关注特定的提交组。
2019-11-26 cs.SE
Learning from Mistakes: Understanding Ad-hoc Logs through Analyzing Accidental Commits
本文通过分析意外提交和直播编码视频，研究开发人员使用临时日志的实践，收集27GB数据揭示其在异步函数中的使用倾向，为改进相关实践提供实证与数据集。
2025-04-17 cs.SE
Mea culpa: How developers fix their own simple bugs differently from other developers
基于SStuBs数据集研究代码作者身份对漏洞修复提交的影响，发现原作者修复简单漏洞的速度更快且提交规模更大，而其他开发者的修复更小且专注，为定制化修复工具提供了依据。
2021-03-22 cs.SE
Untangling Fine-Grained Code Changes
在工作一段时间后，开发人员将他们的代码更改提交到版本控制系统。在这样做时，他们经常捆绑不相关的更改（例如，错误修复和重构），从而创建所谓的纠结提交。共享混乱的提交是有问题的，因为它使这些提交的审查、恢复和集成变得更加困难，并且项目的历史分析不太可靠。研究人员一直致力于解开现有的提交，即，查找提交的哪个部分与哪个任务相关。在本文中，我们以两种方式为这一工作做出贡献：（1）一个公开的未纠缠代码更改数据集，在两个开发人员的帮助下创建，他们在四个月内准确地将代码更改拆分为自包含的任务;（2）一种新颖的方法，EpiceaUntangler，帮助开发人员共享未纠缠的提交（又名。原子提交）。EpiceaUntangler基于公开可用的数据集进行测试，并通过将其部署给7名开发人员进行进一步评估，这些开发人员使用了2周。我们记录了91%的平均成功率和75%的平均成功率，在自动创建未纠缠的细粒度代码更改的集群。
2015-02-24 cs.SE
ZeroIn: Characterizing the Data Distributions of Commits in Software Repositories
现代软件开发是基于一系列快速增量更改，这些更改由具有不同经验和专业知识水平的开发人员对大型源代码存储库进行协作。ZeroIn项目旨在分析这些动态现象的元数据，包括关于存储库、提交和开发人员的数据，以快速准确地标记提交到达存储库时的质量。在这种情况下，本文提出了一个表征的软件开发元数据的分布数据，最好的捕捉趋势的数据集。为此，我们分析了多个数据集，包括开发人员特性的Stack Overflow和超过4.52亿个存储库的GitHub数据，其中包含1600万次提交。这种表征旨在使生成多个合成数据集成为可能，这些数据集可用于训练和测试基于机器学习的新解决方案，以提高软件的可靠性，即使它在发展。它还旨在服务于开发过程，以利用跨存储库和开发人员的聚合空间的许多关键特征向量之间的潜在相关性。本文的数据特征化旨在为ZeroIn的机器学习组件提供信息，包括应用二进制分类器来早期标记有缺陷的软件提交，以及开发基于图的学习方法来利用存储库、提交和开发人员之间的稀疏连接。
2022-04-16 cs.SE
Beyond the Commit: Developer Perspectives on Productivity with AI Coding Assistants
Carnegie Mellon University（卡内基梅隆大学）；BNY Mellon（纽约梅隆银行）
本研究通过混合方法分析了AI代码助手对开发者生产力影响的多维评估因素，强调长期指标的重要性，为未来研究和工业实践提供参考。
2026-02-03 cs.SE
What Makes a Good Commit Message?
协作软件开发中的一个关键问题是开发人员之间的沟通。一种通信方式是提交消息，开发人员在其中描述他们在存储库中所做的更改。因此，提交消息作为一种“审计跟踪”，开发人员可以通过它了解项目的源代码是如何更改的以及更改的原因。因此，提交消息的质量会影响开发人员之间通信的有效性。提交消息通常质量很差，因为开发人员缺乏时间和动力来制作好的消息。已经提出了几种自动方法来生成提交消息。然而，这些都是基于未经策划的数据集，包括相当大比例的措辞拙劣的提交消息。在这个多方法研究中，我们首先定义什么是“好”的提交消息，然后使用来自五个高度活跃的开源项目的近1,600条消息的样本来确定提交消息中缺少信息的比例。我们发现，平均约44%的消息可以得到改进，这表明使用未经策划的数据集可能是使用此类数据训练提交消息生成器时的主要威胁。我们还观察到，以前的工作没有考虑提交消息的语义，并且令人惊讶的是，编写好的提交消息的指导很少。为此，我们开发了一个基于提交消息表达式中重复出现的模式的分类法。最后，我们调查是否可以自动识别“好”的提交消息，这样的自动化可以促使开发人员编写更好的提交消息。
2022-02-07 cs.HC cs.SE
A Dataset and an Approach for Identity Resolution of 38 Million Author IDs extracted from 2B Git Commits
从开源项目中收集的数据提供了对大型软件生态系统建模的方法，但通常存在数据质量问题，特别是代码提交中的多个作者标识字符串实际上可能与一个开发人员相关联。虽然已经提出了许多方法来解决这个问题，但它们要么是需要手动调整的算法，要么需要太多的计算时间来对例如World of Code集合中的38M作者ID进行成对比较。在本文中，我们提出了一种方法，该方法可以在整个数据集中找到属于单个开发人员的所有作者ID，并共享被发现具有别名的所有作者ID的列表。为此，我们首先创建可能相关的作者ID块，然后使用机器学习模型来预测这些可能相关的ID中哪些属于同一个开发人员。我们处理了大约3800万个作者ID，发现大约1480万个ID有别名，属于540万个不同的开发人员，每个开发人员的别名中位数为2。该数据集可用于在整个OSS生态系统级别创建更准确的开发人员行为模型，并可用于提供快速解析新作者ID的服务。
2020-03-27 cs.SE
A Global Author-Identity Map for the World of Code:62.7M Developer Identities from 106.8M Author Strings over 5.87B Commits
University of Tennessee, Knoxville（田纳西大学诺克斯维尔分校）
研究全球软件仓库作者身份映射难题，提出含四个工件的方法，构建无巨型集群映射，提高人工身份提交覆盖率，揭示聚类问题及映射精度真相，与黄金集对比有一定召回率和精度，工件随版本发布。
2026-07-08 cs.SE
Following Breadcrumbs in Code: What Accidentally Committed Ad-Hoc Logs Reveal about Developer Comprehension
University of California, Irvine（加州大学尔湾分校）；Amazon（亚马逊）；ETH Zürich（苏黎世联邦理工学院）
本研究通过挖掘含临时日志的意外提交和分析实时编程会话，构建了多语言大型数据集，揭示了开发者使用临时日志的模式，为调试和日志工具开发提供了实证依据与数据集。
2026-10-09 cs.SE
Chat activity is a better predictor than chat sentiment on software developers productivity
最近的研究表明，软件开发人员的积极情绪对软件开发人员的生产力有积极的影响。在本文中，我们调查了两个数据源：开发人员聊天消息（来自Slack和Hipchat）和单个位于同一地点的敏捷团队超过200个工作日的源代码提交。我们的回归分析表明，聊天消息的数量是最好的预测因素，可以预测提交数量和代码行数的生产力，$R^2$分别为0.33和0.27。然后，我们添加情感分析变量，直到我们模型的AIC不再改善，并获得$R^2$值0.37（提交）和0.30（代码行）。因此，分析聊天情绪可以单独提高聊天活动的生产力预测，但差异并不大。这项工作支持了情绪状态和生产力在软件开发中相互联系的观点。我们发现，三个积极的情绪指标，但令人惊讶的是，也有一个消极的情绪指标与更高的生产力。
2020-04-21 cs.SE
Optimization is Better than Generation: Optimizing Commit Message Leveraging Human-written Commit Message
针对现有提交消息生成技术易遗漏开发者考量的上下文、自动化工具难获取相关信息的问题，提出结合大语言模型与搜索式优化的提交消息优化方法，以人工撰写消息为起点迭代优化，生成的消息质量显著优于现有最优方法和人工撰写结果。
2025-01-16 cs.SE
SZZ in the time of Pull Requests
在多提交开发模型中，程序员完成任务（例如，实现一个功能），将他们的工作组织成几个提交，并将它们打包成一个提交集。使用此模型分析来自开发人员的数据对于解决具有挑战性的开发人员需求非常有用，例如了解哪些功能引入了错误以及评估在发布中集成某些功能的风险。然而，要做到这一点，首先需要确定修复诱导提交集。对于这样的识别，SZZ算法是最自然的候选者，但其性能尚未在多提交上下文中进行评估。在这项研究中，我们进行了深入的调查的可靠性和性能的SZZ在多提交模型。为了获得可靠的基础事实，我们考虑一个已经存在的SZZ数据集，并将其适应多提交上下文。此外，我们还设计了第二个数据集，它更广泛，直接由Mozilla的开发人员和质量保证（QA）工程师创建。基于这些数据集，我们（1）在多提交模型的上下文中测试B-SZZ及其非语言特定的SZZ变体的性能，（2）调查其特定行为背后的原因，（3）分析提交集中不相关提交的影响，并在使用SZZ之前自动检测它们。
2022-09-07 cs.SE
On Relating Technical, Social Factors, and the Introduction of Bugs
随着协作编码环境使软件项目更容易做出贡献，参与这些项目的开发人员数量不断增加。这种增加使得代码审查者更难处理有bug的贡献。像GitHub这样的协作环境提供了关于开发人员贡献的丰富数据源。这样的数据可以用于提取关于开发者的关于技术的信息（例如，他们的经验）和社会（例如，的相互作用）因素。最近的研究分析了这些因素对软件开发的不同活动的影响。然而，在这些因素与错误引入之间的关系方面仍有改进的余地。我们提出了一个更广泛的研究，包括来自不同领域的8个项目和6，537个错误报告，涉及五个技术因素，三个社会因素和错误的介绍。结果表明，技术和社会因素可以区分错误和干净的承诺。但是，技术因素比社会因素更具决定性。特别是，开发人员不遵守技术贡献规范的习惯和开发人员的提交缺陷与提交缺陷的增加有关。另一方面，项目的建立、开发者提交的所有权级别和社会影响力与引入错误的机会较低有关。
2020-04-07 cs.SE
Evaluating SZZ Implementations Through a Developer-informed Oracle
SZZ算法用于识别错误引起的变化已被广泛用于评估缺陷预测技术和经验调查何时，如何以及由谁引入错误。多年来，研究人员提出了几种方法来提高SZZ的准确性，提供了各种SZZ的实现。然而，在一个可靠的oracle上公平地评估这些实现是一个悬而未决的问题：SZZ评估通常依赖于（i）对SZZ输出的手动分析，以将识别出的bug诱导提交分类为真或假阳性;或者（ii）链接bug修复和bug诱导提交的黄金集。在这两种情况下，这些人工评估都是由对所研究的主题系统知识有限的研究人员进行的。理想情况下，应该有一个由所研究系统的原始开发人员创建的黄金集。我们提出了一种方法来建立一个“开发人员知情”的预言SZZ变种的评估。我们使用自然语言处理（NLP）来识别bug修复提交，其中开发人员显式引用引入已修复bug的提交。随后是手动过滤步骤，旨在确保神谕的质量和准确性。一旦构建完成，我们就使用oracle来评估SZZ算法的几个变体的准确性。我们的评估帮助我们提取了一组经验教训，以进一步改进SZZ算法。
2021-02-05 cs.SE
Different Debt: An Addition to the Technical Debt Dataset and a Demonstration Using Developer Personality
本文扩展 Technical Debt Dataset，覆盖 37 个项目全分支 278,320 次提交，并复现开发者个性研究，得到与既有工作不同的 TD 引入与移除关系。
2024-03-02 cs.SE
Rationale Dataset and Analysis for the Commit Messages of the Linux Kernel Out-of-Memory Killer
本文构建了 Linux 内核 OOM Killer 组件提交信息的带标签数据集，分析理由信息的存在、演变与结构，发现 98.9% 的提交包含理由且经验丰富开发者约 60% 的句子报告理由。
2024-02-06 cs.SE
GitCF: Reducing Incomplete Changes by Exploiting Multiple Similarities Among Commits
School of Computing Institute of Science Tokyo（东京科学大学理工学院）
GitCF通过结合提交中修改元素集合与文本内容两类相似性，推荐额外变更位置，在17个开源项目的543个不完整变更上，五项指标均优于现有基线，显著提升Hit@10。
2026-09-30 cs.SE
The Co-Evolution of Test Maintenance and Code Maintenance through the lens of Fine-Grained Semantic Changes
自动化测试是一种被广泛采用的提高软件质量的技术。作为软件开发过程的一部分，以及在初始发布后的演变阶段，软件开发人员添加、删除和更新测试方法和测试类。在这项工作中，我们进行了大规模的研究，61个流行的开源项目，并报告之间的关系，我们已经建立了测试维护，生产代码维护，语义变化（例如，语句添加，方法删除等）。在开发人员的提交中执行。我们建立了预测模型，并表明软件项目中的测试数量可以通过使用代码维护配置文件（即，在每个维护活动中执行了多少次提交：纠正、完善、自适应）。我们的研究结果还表明，开发人员在同一提交中执行代码修复而不执行补充测试维护（例如，更新现有测试或添加新测试）。当开发人员执行测试维护时，很可能会受到他们作为提交的一部分执行的语义更改的影响。我们的工作是基于研究61个流行的开源项目，包括超过240，000个提交，其中包括超过16，000，000个语义更改类型实例，由超过4，000名软件工程师执行。
2017-09-26 cs.SE
An Empirical Comparison of Developer Retention in the RubyGems and npm Software Ecosystems
软件生态系统可以被看作是由技术组件（软件包）和维护技术组件的社会组件（开发人员社区）组成的社会技术网络。随着时间的推移，生态系统通过社会技术变化而演变，这些变化可能会极大地影响生态系统的可持续性。像开发人员流动这样的社会变化可能会导致技术退化。这激发了识别导致开发人员放弃的那些因素的需要，以便自动化识别具有高放弃风险的开发人员的过程。本文比较了两个软件包生态系统RubyGems和npm的这些因素。我们分析了他们在GitHub上托管的软件包的演变，考虑了提交方面的开发活动，以及与其他开发人员在提交、问题或拉取请求相关的评论方面的社交互动。我们分析了RubyGems和npm分别超过3万和6万开发人员的社会技术活动。我们使用生存分析来确定哪些因素与较低的生存概率相一致。我们的研究结果表明，开发人员放弃生态系统的可能性更高：不与其他开发人员进行讨论;没有很强的社交和技术活动强度;沟通或提交频率较低;并且长时间不参与技术和社交活动。这些观察结果可用于自动识别放弃生态系统的可能性很高的开发人员，从而降低与知识损失相关的风险。
2017-08-08 cs.SE
Developer Productivity With and Without GitHub Copilot: A Longitudinal Mixed-Methods Case Study
University of Oslo（奥斯陆大学）；SINTEF（辛特夫研究所）
研究通过混合方法案例研究分析GitHub Copilot对开发者活动和主观生产力的影响，发现使用Copilot的开发者活动更活跃，但无显著统计学变化，表明提交指标与主观生产力体验存在差异。
2026-01-28 cs.SE
Towards Understanding and Analyzing Rationale in Commit Messages using a Knowledge Graph Approach
本研究构建Kantara端到端设计rationale重构流水线，通过知识图谱结构化提交消息中的rationale信息并提取分类，同时构建Linux内核OOM组件标注数据集，评估显示XGBoost等NLP分类技术效果良好。
2023-09-04 cs.SE
Bridging the Gap: A Comparative Study of Academic and Developer Approaches to Smart Contract Vulnerabilities
本文通过比较学术与开发者在修复智能合约漏洞策略上的差异，揭示了实际开发中存在与学术文献不一致的漏洞处理方法，并识别出27种新型修复策略。
2026-01-12 cs.SE
Towards Identifying Paid Open Source Developers - A Case Study with Mozilla Developers
开源开发包含来自雇佣和志愿软件开发人员的贡献。当我们考虑研究成果向闭源软件行业的可转移性时，识别这种状态是很重要的，因为它们不包括志愿者开发人员。虽然许多研究都考虑了开发人员的就业状况，但由于缺乏准确的自动方法，这些信息通常是手动收集的。在本文中，我们提出了使用机器学习预测有偿和无偿开源开发的第一步，并将我们的结果与先前工作中使用的自动技术进行比较。通过依赖Mozilla的代码源存储库元数据，以及手动收集的就业状况，我们构建了一个最活跃的开发人员数据集，包括志愿者和Mozilla雇佣的开发人员。我们根据开发人员通常的提交时间模式定义了一组指标，并使用不同的分类方法（逻辑回归，分类树和随机森林）。结果表明，我们提出的方法使用随机森林以0.75的AUC识别付费和未付费提交，这高于使用先前使用的最佳自动方法获得的0.64的AUC。
2018-04-06 cs.SE
Commit Messages in the Age of Large Language Models
本研究评估ChatGPT基于代码变更生成提交消息的性能，发现其效果远超专门训练的现有ACMG方法，生成消息准确高质，同时对失效案例进行了分类分析。
2024-02-02 cs.SE
The Corrective Commit Probability Code Quality Metric
The Hebrew University of Jerusalem（耶路撒冷希伯来大学）
我们提出了一个代码质量度量，纠正提交概率（CCP），测量的概率，提交反映纠正性维护。我们表明，这个指标符合开发人员的质量，信息和稳定的概念。通过将语言模型应用于提交消息来识别纠正提交。通过将语言模型应用于提交消息来识别纠正提交。我们计算了所有大型活跃GitHub项目的CCP（2019年至少有200个提交的7，557个项目）。这导致了一个质量等级的创建，表明质量最低的10%的项目在修复bug上花费的精力至少是前10%的6倍。对项目属性的分析表明，较低的CCP（较高的质量）与较小的文件，较低的耦合，使用JavaScript和C#等语言而不是PHP和C++，更少的开发人员，更低的开发人员流失，更好的入门和更高的生产力有关。除其他外，这些结果支持“质量是免费的”的说法，并建议实现更高的质量不需要更高的费用。
2020-07-21 cs.LG cs.SE
Finding Relationships between Socio-Technical Aspects and Personality Traits by Mining Developer E-mails
人格特质影响着大多数（如果不是全部的话）人类活动，从人们走路、说话、穿衣和写作的方式，到与他人互动的方式。最重要的是，个性会影响人们做决定的方式，包括在开发人员的情况下，他们在选择他们想要参与的软件项目时所考虑的标准。大多数研究软件开发项目中社会、技术和人为因素的影响的工作都集中在软件质量中沟通的影响上。例如，在发布软件产品的增强版本之前，识别预测器以检测可能包含错误的文件。这些作品中只有少数关注自由/自由和开源软件项目中具有提交权限的开发人员（提交者）的个性特征及其与他们交互的软件工件的关系。本文提出了一种方法，自动识别的基础上，从电子邮件发送的提交人在FLOSS项目的个性特征，揭示在软件开发过程中发生的社会和技术方面之间的关系。我们的实验结果表明，提交者通过他们的电子邮件和他们进行的社会（沟通）和技术活动所投射的人格特质之间存在一些关系。这项工作是一个初步的研究，旨在支持建立有效的工作团队，在软件开发项目的基础上，考虑到他们的个性特征的利益相关者的适当组合。
2016-03-03 cs.SE
Brevity is the Soul of Wit: Condensing Code Changes to Improve Commit Message Generation
本文提出用包含概括变更、提炼注释和强调标识符的简洁模板压缩代码变更，并微调CodeLlama-7B生成提交信息，在多个指标上显著优于基线。
2025-09-19 cs.SE
ALFAA: Active Learning Fingerprint Based Anti-Aliasing for Correcting Developer Identity Errors in Version Control Data
开发人员网络图对于软件工程的研究和实践具有重要意义。为了让这些图真实地表示网络，准确的开发人员身份是必不可少的。我们的目标是从开源软件存储库中识别开发人员身份错误，调查这些错误的性质，设计纠正算法，并估计这些错误对从这些数据推断的网络的影响。我们使用超过1B的Git提交和超过23M的记录作者身份来调查这些问题。通过检查最频繁出现的作者字符串，我们将标识错误分为几类。然后，我们用3个行为指纹来增加作者字符串：时区频率，修改的文件集，以及提交消息的向量嵌入。我们使用主动学习方法为一部分OpenStack开发人员创建了一组手动验证的身份，并使用它来拟合监督学习模型，以预测OpenStack中剩余作者字符串的身份。我们将这些预测与商业努力和领先的研究方法进行比较。最后，我们比较网络措施的文件诱导作者网络的基础上校正和原始数据。我们发现来自不同环境的提交、拼写错误、组织ID、默认值和匿名ID是错误的主要来源。我们还发现，与现有方法相比，监督学习方法可以将错误减少数倍，而主动学习方法是创建验证数据集的有效方法，并且开发人员身份的纠正对社交网络的推理有很大影响。我们相信，我们提出的主动学习基于指纹的抗锯齿（ALFAA）的方法将加快研究进展，在软件工程领域的应用程序，依赖于开发人员或其他社交网络的图形。
2019-01-10 cs.SE
AI-Powered Commit Explorer (APCE)
Department of Mathematics, Computer Science, and Data Science, Belmont University（数学、计算机科学与数据科学系，贝尔蒙特大学）；Department of Computer Science, Drexel University（计算机科学系，德雷塞尔大学）；Department of Computer Science, Florida State University（计算机科学系，佛罗里达州立大学）
本文提出APCE工具，支持存储多种LLM提示词、通过额外评估提示词增强提交信息，并提供自动化与人工评估机制，以帮助开发者和研究人员更好地使用和研究LLM生成的提交信息。
2025-07-21 cs.AI cs.SE
D-Diff: An Interactive Environment for Adjusting Commit Boundaries Based on an Editable 3-way Diff
School of Computing, Institute of Science Tokyo（东京科学大学理工学院）
D-Diff是针对含相同单一文件的连续提交的交互式差异调整环境，整合两路差异为紧凑视图，用户研究显示其效率显著优于基准工具，获更高可用性反馈且准确性无显著差异。
2026-08-25 cs.SE
Utilizing Source Code Syntax Patterns to Detect Bug Inducing Commits using Machine Learning Models
本研究提出从源代码语法模式中提取特征来检测引入缺陷的提交，实验表明该方法在多种机器学习模型上提升了缺陷检测性能，并提供了更好的可解释性。
2022-12-07 cs.SE
Using Developer Discussions to Guide Fixing Bugs in Software
The University of Texas at Austin（德克萨斯大学奥斯汀分校）
自动修复软件错误是一项具有挑战性的任务。虽然最近的工作表明，自然语言上下文在指导bug修复模型方面很有用，但这种方法需要提示开发人员提供这种上下文，这是通过在bug修复代码更改后编写的提交消息来模拟的。相反，我们建议使用bug报告讨论，这在任务执行之前就可以使用，并且也是自然发生的，避免了对开发人员任何额外信息的需求。为此，我们用bug报告讨论来增加标准的bug修复数据集。使用这些新编译的数据集，我们证明了从这些讨论中派生的各种形式的自然语言上下文可以帮助修复错误，甚至可以提高性能，而不是使用对应于Oracle错误修复提交的提交消息。
2022-11-11 cs.CL cs.SE
(No) Influence of Continuous Integration on the Commit Activity in GitHub Projects
持续集成（CI）的核心目标是对软件项目进行小的增量更改，这些更改经常集成到主线存储库或分支中。本文提出了一个实证研究，调查如果开发人员调整他们的提交活动对上述目标后，项目开始使用CI。我们分析了93个GitHub项目中的提交和合并活动，这些项目引入了托管CI系统Travis CI，但在引入CI之前已经开发了至少一年。在我们的分析中，我们只发现了一个不可忽略的影响，即合并比率的增加，这意味着在项目开始使用Travis CI之后，合并提交相对于所有提交来说更多。这种效应在相关的研究中也有报道。然而，我们在60个未使用CI的GitHub项目的随机样本中观察到了同样的效果。因此，这种影响不太可能是单独引入CI引起的。我们的结论是：（1）在我们的项目样本中，CI的引入并没有导致开发人员的提交活动发生重大变化，（2）在将效果归因于可能不是观察到的效果的原因的治疗之前，将提交活动与基线进行比较是很重要的。
2018-09-14 cs.SE
COMET: Generating Commit Messages using Delta Graph Context Representation
Dalhousie University（达尔豪斯大学）
针对提交消息生成中上下文捕获不足的问题，提出基于增量图表示和Transformer的Comet方法，在多个指标上优于现有技术及GPT模型，可用于生成上下文感知的提交消息。
2024-02-02 cs.AI cs.CL cs.SE
Consider What Humans Consider: Optimizing Commit Message Leveraging Contexts Considered By Human
针对自动化 CMG 遗漏开发者实际依赖上下文的问题，提出 CMO，从人工提交信息出发，结合 LLM、搜索优化、关键上下文与外部评估反馈迭代改进，显著优于现有方法及人工信息。
2025-03-18 cs.SE
An empirical evaluation of the usefulness of Tree Kernels for Commit-time Defect Detection in large software systems
在提交签入时进行缺陷检测可以防止缺陷引入软件系统。目前的缺陷检测方法依赖于基于度量的模型，这些模型不是很准确，并且其结果对开发人员没有直接的用处。我们提出了一种方法来检测bug诱导提交通过比较传入的更改与项目中所有过去的提交，同时考虑那些引入缺陷和那些没有。我们的方法在方法级的粒度上单独考虑提交中的单个更改。这样做有助于开发人员，因为他们被告知需要进一步关注的特定方法，而不是被告知整个提交都有问题。我们的方法将源代码表示为抽象语法树，并使用树内核来估计代码与以前提交的相似性。我们使用子树内核（STK），子集树内核（SSTK）或部分树内核（PTK）进行实验。然后使用K-NN分类器对过去的更改进行分类。我们使用NiCad克隆检测器作为基线，在BigCloneBench基准和Technical Debt数据集上评估我们的方法。我们的BigCloneBench基准测试的实验表明，树内核的方法可以检测克隆与NiCad的MAP相当。此外，在使用Technical Debt数据集进行缺陷检测时，树核的效率最低，MRR、F分数和准确度分别为0.87、0.80和0.82。
2021-06-21 cs.SE
Help Me to Understand this Commit! -- A Vision for Contextualized Code Reviews
本文针对现代代码审查中代码理解支持不足的问题，通过分类53篇论文并结合审查者需求，提出了情境化代码审查环境的愿景，以提升审查有效性并降低开发者认知负荷。
2024-02-14 cs.SE
Analysis of Commit Signing on Github
University of Tennessee（田纳西大学）
研究分析GitHub提交签名的使用情况，发现签名率 misleading，开发者难以保持一致性，签名 lapse率随账户年龄增加，开发者管理签名密钥不当，导致供应链安全框架假设不成立。
2026-07-27 cs.CR cs.SE
Using Large Language Models for Commit Message Generation: A Preliminary Study
本文通过实验评估Llama 2和ChatGPT在提交信息生成中的表现，发现大语言模型在人工评估中显著优于现有方法，并揭示了常用自动评估指标的局限性。
2024-01-13 cs.SE
CoMRAT: Commit Message Rationale Analysis Tool
针对开源提交消息理由研究有限的问题，提出CoMRAT工具，可分析提交消息中的决策与理由句，支持研究人员生成Github模块理由指标、开发者自查理由含量，初步验证其实用性与易用性。
2025-02-27 cs.SE
Assessing Practitioner Beliefs about Software Defect Prediction
仅仅因为软件开发人员说他们相信“X”，并不一定意味着“X”是真的。正如这里所示，在最近的软件工程文献中列出了许多信念，这些信念只得到一小部分可用数据的支持。因此，我们要问，信念和证据之间的这种脱节的根源是什么？为了回答这个问题，我们在数十个开源项目中看到的30万多个变化中寻找十个信念的证据。其中一些信念在所有项目中都得到了强有力的支持;特别是，“涉及更多添加和删除行的提交更容易出现bug”和“由其所有者（贡献最多更改的人）贡献较少行的文件更容易出现bug”。大多数被研究的广泛持有的信念在数据中只得到零星的支持;即大的影响可能出现在项目数据中，然后在随后的发布中消失。这种零星的支持解释了为什么开发人员相信与他们以前的工作相关的东西，但不一定是他们当前的工作。我们的结论是，我们需要改变与软件工程争论的性质。具体而言，虽然报告当前有效的影响很重要，但报告随着时间的推移会发生哪些影响也很重要。
2020-04-08 cs.SE
A Survey on What Developers Think About Testing
本调查基于284名开发者的回复，探究开发者对测试的真实态度，发现测试动机受质量追求与个人满足感驱动，但被视为单调任务，建议通过更好认可来改善。
2023-09-03 cs.SE
Watch out for This Commit! A Study of Influential Software Changes
一个单一的代码更改可能会对广泛的软件系统及其用户产生重大影响。例如，1）添加新功能可能会将缺陷分散到多个模块中，而2）更改API方法可以提高所有客户端程序的性能。开发人员在提交时通常不清楚他们或其他人的更改是否有影响力。相反，它在影响系统的许多方面之后才有影响力。本文研究了有影响力的软件变更，并提出了一种方法来识别他们早期，即，当它们被应用时。我们首先进行了事后分析，发现现有的影响力的变化，通过使用的直觉，如孤立的变化和变化所涉及的其他变化在10个开源项目。然后，我们通过一个开放的卡片排序过程对所有已识别的更改进行重新分类。随后，我们对89名开发人员进行了调查，以确认我们有影响力的变化类别。最后，我们从我们的地面真相中提取特征，包括变更的复杂性、提交日志中的术语和协同变更图中的文件中心性等指标，以构建机器学习分类器。实验结果表明，我们的预测模型在随机样本的情况下分别达到了86.8%的准确率、74%的召回率和80.4%的F-测度。
2016-06-10 cs.SE
LLM-based Code Auditing by Inferring and Evaluating Developer Assumptions
MPI-SP（马克斯·普朗克安全与隐私研究所）；CISPA（萨姆·哈塞尔大学赛斯帕信息安全和隐私中心）
本研究提出基于大语言模型的Creed方法，通过推断评估开发者安全信念检测代码漏洞，在真实基准上实现了优于现有工具的效果-工作量权衡。
2026-10-14 cs.CR cs.SE
A Multi-Month Study of Git Commit Signing
University of Tennessee , Knoxville（田纳西大学诺克斯维尔分校）
本研究对22名计算机科学专业学生开展三个月Git提交签名使用研究，发现其存在配置阻碍、难发现异常提交、对签名保障存误解等问题，指出仅简化签名不足以保障安全使用，还需配套工具与教育支持。
2026-09-01 cs.CR cs.SE
On the Use of Commit Messages for Corrective Software Maintenance: A Systematic Mapping Study
Télécom Paris, Institut Polytechnique de Paris（巴黎电信学院，巴黎理工学院）
本文通过系统映射研究97篇2004至2025年发表的文献，探讨提交信息在纠正性维护中的应用，发现提交信息在 bug 分析和修复识别中作用显著，但其他领域如自动程序修复研究较少。
2026-03-31 cs.SE
Code Ownership: The Principles, Differences, and Their Associations with Software Quality
本文研究了基于提交和基于行的代码所有权近似在开发者集合、所有权值及专业知识水平上的差异，发现基于提交的近似与软件质量关联更强，建议分别将其用于质量改进和问责目的。
2024-08-23 cs.SE
Towards Exploring the Code Reuse from Stack Overflow during Software Development
作为最知名的程序员问答网站之一，Stack Overflow（即，SO）每天为数万名开发者提供服务。以前的工作表明，许多开发人员在SO上重用代码片段，当他们找到一个答案（来自SO），功能上匹配他们在开发活动中遇到的编程问题。为了研究程序员在项目开发过程中如何重用SO上的代码，我们进行了全面的实证研究。首先，为了捕捉程序员的开发活动，我们从793个开源Java项目的提交中收集了342，148个修改过的代码片段，这些修改过的代码可以反映开发过程中遇到的编程问题。我们还从SO上的1，355，617个帖子中收集了代码片段。然后，我们使用CCBACK来检测提交的修改代码与SO的代码之间的代码克隆，并进一步分析程序员在开发过程中解决编程问题时的代码重用。我们统计了不同年份每个项目提交中修改后的代码片段的代码重用率，结果显示代码重用率平均为6.32%，最高为8.38%。项目提交中的代码复用率逐年上升，新成立项目的代码复用比例高于老项目。我们还发现有些项目重用了很多年前的代码片段。此外，我们发现，有经验的开发人员似乎更有可能重用SO上的知识。此外，我们发现，在bug相关的提交（6.67%）的代码重用率略高于在非bug相关的提交（6.59%）。此外，我们还发现，代码重用率（14.44%）在Java类文件中，经历了多次修改是两倍以上的整体代码重用率（6.32%）。
2022-04-27 cs.SE
A Purpose-oriented Study on Open-source Software Commits and Their Impacts on Software Quality
本研究针对不同类别提交对开源软件质量影响的研究不足，对提交进行分类并训练预测模型实现自动化分类，进而探究不同目的提交对质量的影响，最终建立新的提交更改指南以提升软件质量。
2025-03-04 cs.SE
Gamekins: Gamifying Software Testing in Jenkins
开发人员必须为他们的软件编写全面的测试，以发现bug并防止回归。然而，编写测试并不是每个开发人员最喜欢的职业，如果缺乏动机导致缺乏测试，那么这可能会产生可怕的后果，例如程序质量差甚至项目失败。本文介绍了Gamekins，一个使用游戏化来激励开发人员编写更多更好的测试的工具。Gamekins集成到Jenkins持续集成平台中，游戏元素基于对源代码存储库的提交：开发人员可以通过完成Gamekins提出的测试挑战和任务获得积分，与其他开发人员或开发团队在排行榜上竞争，并因其测试相关成就而获得奖励。
2022-02-14 cs.SE
Apples, Oranges & Fruits -- Understanding Similarity of Software Projects Through The Lens of Dissimilar Artifacts
开源项目的日益增长的可用性促进了开发人员重用现有的软件工件并利用它们开发新软件。然而，很难理解相似性的概念，因为它因开发人员而异。有些开发人员可能会搜索具有类似源代码的存储库，而有些开发人员可能会搜索具有类似需求或问题的存储库。现有的方法倾向于通过比较类似的工件来找到类似的项目，例如源代码与源代码，API使用与API使用，文档与文档等。即使两个类似的工件之间存在差异，两个不同的工件之间也可能存在相似性。因此，在本文中，我们的目标是回答这个问题-我们可以通过不同的工件找到软件存储库的相似性吗？为此，我们进行了一个实验，以找到三个存储库之间的相似之处，两个类似的项目和一个不同的项目比较相似和不同的工件（文档，提交和源代码）。我们观察到了不同工件之间的相似性，例如在相似和不同存储库的上下文中的提交、源代码和自述文件。
2021-03-02 cs.SE
How We Refactor and How We Document it? On the Use of Supervised Machine Learning Algorithms to Classify Refactoring Documentation
Rochester Institute of Technology（罗切斯特理工学院）；ETS Montreal, University of Quebec（魁北克大学蒙特利尔分校）；University of Michigan（密歇根大学）
重构是一种在不改变系统外部行为的情况下改进系统设计的艺术。重构已经成为一个完善的和有纪律的软件工程实践，已经吸引了大量的研究假设重构的主要动机是需要改善系统结构。然而，最近的研究表明，开发人员可能会将重构纳入其他开发活动中，而不仅仅是改进设计。不幸的是，这些研究仅限于开发人员访谈和一组减少的项目。为了克服上述限制，我们的目标是通过挖掘和分类从800个Java项目中提取的111，884个包含重构的提交来更好地理解是什么促使开发人员应用重构。我们训练了一个多类分类器，将这些提交分为3个类别，即内部QA，外部QA和代码验证解决方案，以及传统的BugFix和Functional类别。这种分类挑战了重构的原始定义，它专门用于改进设计和修复代码气味。此外，为了更好地理解我们的分类结果，我们分析了提交消息，以提取开发人员经常用来描述其重构的文本模式。结果表明：（1）修复代码气味不是开发人员重构代码库的主要驱动力。请求重构的原因有很多，超出了它的传统定义;（2）重构的分布在生产和测试文件之间不同;（3）开发人员使用几种模式来有目的地针对重构;（4）从提交消息中提取的文本模式为开发人员如何记录他们的重构提供了更好的覆盖。
2020-10-26 cs.LG cs.SE
Toward the Automatic Classification of Self-Affirmed Refactoring
Rochester Institute of Technology（罗切斯特理工学院）；ETS Montreal, University of Quebec（魁北克大学蒙特利尔工程技术学院）
自我确认重构（SAR）的概念被引入来探索开发人员如何在提交消息中记录他们的重构活动，即，开发人员在代码更改期间有意引入的重构操作的显式文档。在我们之前的研究中，我们已经手动识别了重构模式，并定义了三个主要的常见质量改进类别，包括内部质量属性，外部质量属性和代码气味，只考虑重构相关的提交。然而，这种方法严重依赖于提交消息的手动检查。在本文中，我们提出了一个两步的方法，首先确定一个提交是否描述了开发人员相关的重构事件，然后根据重构常见的质量改进类别进行分类。具体来说，我们结合了N-Gram TF-IDF特征选择与二进制和多类分类器，建立一个新的模型来自动分类的重构的基础上，他们的质量改进类别。我们使用从精心设计的开源Java项目中提取的总共2，867条提交消息来挑战我们的模型。我们的研究结果表明，（1）我们的模型能够准确地分类SAR提交，优于基于模式和随机分类器的方法，并允许发现40个更相关的SAR模式，（2）即使使用相对较小的训练数据集，我们的模型也达到了高达90%的F-测量。
2020-09-19 cs.LG cs.SE
