Analyzing the Effects of CI/CD on Open Source Repositories in GitHub and GitLab
许多文章强调了在软件开发中实现持续集成和交付（CI/CD）管道的好处。这些管道有望提高项目的声誉，并减少存储库中的提交和问题数量。虽然CI/CD的采用最初可能会很慢，但从长远来看，它可以加速服务的交付和部署。本研究旨在调查CI/CD对两个开源存储库GitLab和GitHub中的提交速度和问题数量的影响。通过分析超过12，000个存储库并记录每个提交和问题，我们发现CI/CD将提交速度提高了141.19%，但问题数量也增加了321.21%。
2023-03-29 cs.SE
Evaluating a bot detection model on git commit messages
为了防止大规模社会技术实证分析中的偏见，检测分布式软件开发活动中机器人的存在是非常重要的。在以前的工作中，我们提出了一个分类模型，根据GitHub帐户的pull请求和issue评论来检测GitHub存储库中的机器人。目前的研究基于提交消息对git贡献者进行了概括。我们在一个包含6，922个git贡献者的大型数据集上对分类模型进行了训练和评估。基于pull request和issue comments的原始模型在此数据集上获得了0.77的精度。在git commit消息上重新训练分类模型将精度提高到0.80。作为概念验证，我们在BoDeGiC中实现了这个模型，BoDeGiC是一个开源命令行工具，用于检测git存储库中的机器人。
2021-03-22 cs.SE
Dynamics of Team Library Adoptions: An Exploration of GitHub Commit Logs
当一群人努力理解新信息时，各种各样的想法争夺注意力。陡峭的学习曲线随着团队的共同学习而被克服。为了理解这些团队动态在软件开发中是如何发挥作用的，我们探索了Git日志，它提供了软件存储库的完整更改历史。在这些存储库中，我们观察到代码添加，这代表成功实现的想法，以及代码删除，这代表失败或被取代的想法。通过检查这些提交类型之间的模式，我们可以开始理解团队如何采用新信息。我们专门研究软件库被项目采用后会发生什么，即，在项目中首次使用库时。我们发现，各种因素，包括团队规模，库的流行程度和流行的堆栈溢出与团队学习和成功地采用新的软件库的速度有关。
2019-07-10 cs.SE cs.SI
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
CoMRAT: Commit Message Rationale Analysis Tool
针对开源提交消息理由研究有限的问题，提出CoMRAT工具，可分析提交消息中的决策与理由句，支持研究人员生成Github模块理由指标、开发者自查理由含量，初步验证其实用性与易用性。
2025-02-27 cs.SE
VulCurator: A Vulnerability-Fixing Commit Detector
Singapore Management University（新加坡管理大学）；University of Melbourne（墨尔本大学）
开源软件（OSS）漏洞管理过程是当今重要的，因为随着时间的推移，发现的OSS漏洞的数量正在增加。监控可修复性提交是防止漏洞利用的标准流程的一部分。然而，手动检测修复提交是非常耗时的，因为可能有大量的提交需要审查。最近，已经提出了许多技术来使用机器学习来自动检测可修复性提交。这些解决方案要么：（1）没有使用深度学习，要么（2）只在有限的信息源上使用深度学习。本文提出了VulCurator，这是一种利用深度学习更丰富信息源的工具，包括提交消息、代码更改和问题报告，用于修复提交分类的可扩展性。我们的实验结果表明，VulCurator在F1分数方面优于最先进的基线高达16.1%。VulCurator工具可在https://github.com/ntgiang71096/VFDetector和https：//zenodo.org/record/7034132#.Yw3MN-xBzDI上公开获得，演示视频可在https://youtu.be/uMlFmWSJYOE上获得。
2022-09-07 cs.AI cs.CR cs.SE
GitHub's Copilot Code Review: Can AI Spot Security Flaws Before You Commit?
Department of Computer Science（计算机科学系）；Toronto Metropolitan University（多伦多 Metropolitan 大学）
本研究评估了GitHub Copilot代码审查功能检测安全漏洞的能力，发现其难以发现SQL注入等关键漏洞，主要关注代码风格等低严重性问题，表明AI辅助审查仍需结合专门安全工具和人工审查以保障软件安全。
2025-09-17 cs.AI cs.SE
Agentic Much? Adoption of Coding Agents on GitHub
INP, LaBRI, UMR 5800 , Univ. Bordeaux, CNRS（法国国家高等矿业电信学校，拉布里实验室，联合研究单位5800，波尔多大学，法国国家科学研究中心）；Univ. Rennes, Inria, CNRS, IRISA（雷恩大学，法国国家信息与自动化研究所，法国国家科学研究中心，IRISA）；Department of Computer Science , UFMG（计算机科学系，米纳斯吉拉斯联邦大学）；LTCI, Télécom Paris , Institut Polytechnique de Paris（电信巴黎学院，通信与电子实验室，巴黎理工学院）
研究探讨了编码代理在GitHub上的采用情况，发现其采用率高达22.20%-28.66%，且在项目成熟度、组织类型和编程语言上均广泛适用。
2026-04-08 cs.SE
Bug-Fix Variants: Visualizing Unique Source Code Changes across GitHub Forks
分叉是开发人员在现有项目上进行构建时的常见做法。这些分叉创建了变体，这些变体具有共同的代码基础，但随后在不同的方向上发展代码，这是特定于分叉的项目需求的。拥有多个fork的一个有趣的副作用是能够在代码的不同演化方向之间进行选择，这是基于开发人员修复代码库中的bug。然而，关键问题在于，这种分散的信息形式很难分析。在这项研究中，我们提出了一个可视化来分析尚未合并回原始项目的fork存储库中的活动更改。我们的可视化显示了多个fork中的代码提交活动，突出显示了fork历史中的bug修复提交。虽然每个存储库的提交活动的可视化类似于GitHub的代码频率视图，但我们的视图仅显示fork存储库独有的提交。为了说明我们的可视化的有效性，我们将我们的视图应用于两个用例：从不再维护的存储库中识别fork，以及在fork中识别bug修复。在第一种情况下，我们识别了一个名为Obfuscator-LLVM的挂起项目的分支。我们的视图显示了原始存储库及其最活跃的分支，这些分支在顶部继续开发。在第二种情况下，我们在Clipy项目的一个分支中发现了一个bug修复。我们的视图显示，最活跃的分支有自己的bug修复;我们可以很容易地为视图中突出显示的bug识别补丁。作为一个新的想法论文，我们提出了我们的三个研究问题的大纲，以激发现实世界的用例和目标，我们的可视化有可能发现。我们的可视化原型可在\textcolor{…
2022-08-05 cs.SE
How AI Coding Agents Modify Code: A Large-Scale Study of GitHub Pull Requests
University of Nevada Las Vegas（内华达大学拉斯维加斯分校）
研究通过分析GitHub拉取请求中的代码修改，探讨AI代理与人类贡献在提交数量、文件修改和描述一致性上的差异。
2026-04-06 cs.AI cs.SE
JavaVFC: Java Vulnerability Fixing Commits from Open-source Software
本文构建并发布 JavaVFC 与 JavaVFC-extended 数据集，利用关键词启发式、多轮人工标注和大规模仓库筛选，为漏洞修复提交识别与自动修复研究提供数据基础。
2024-09-09 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
A Software Engineering Capstone Course Facilitated By GitHub Templates
针对软件工程顶点课程中工作分配不均和赶工问题，提出使用包含初始基础设施的 GitHub 模板及个人生产力指标监控，初步数据显示截止日提交比例下降，并引入公平性衡量标准，计划未来进行对照实验验证效果。
2024-10-15 cs.CY cs.SE
Evolution of repositories and privacy laws: commit activities in the GDPR and CCPA era
研究分析了GDPR和CCPA时代软件仓库的提交活动，发现隐私相关术语在提交信息中出现，但对用户权利的引用较少，提出需加强隐私教育和工具开发。
2025-05-28 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
Was It Never Collected, or Rewritten Away? A Commit-Provenance Dataset Separating Ingestion Gaps from Upstream History Edits across the World of Code
University of Tennessee, Knoxville（田纳西大学诺克斯维尔分校）
通过比较同一提交图的两种视图，即GHArchive事件流和世界代码（WoC）V2604对象数据库，分离提交缺失的不同原因，构建数据集，分析不同情况比例，发布相关数据及处理结果。
2026-07-07 cs.SE
From First Use to Final Commit: Studying the Evolution of Multi-CI Service Adoption
本研究分析近 1.9 万个 GitHub Java 项目在 2008—2024 年间对八种 CI 服务的采用与迁移，揭示多 CI 共存和替换的普遍模式及维护差异。
2025-07-27 cs.SE
Detecting Continuous Integration Skip : A Reinforcement Learning-based Approach
Laval university（拉瓦尔大学）
针对CI提交跳过检测难、数据不平衡的问题，提出基于深度强化学习的最优决策树分类器，经GitHub开源项目验证效果优于现有前沿方法。
2024-05-15 cs.AI cs.SE
Visual Analysis of GitHub Issues to Gain Insights
本文提出一个原型Web应用，通过可视化GitHub issues时间线与生命周期揭示相关因素，帮助开发者快速理解issue解决过程与项目开发模式。
2024-07-30 cs.HC cs.SE
Deforking the World of Code: A Project-Provenance Map that Recovers Cross-Forge Fork Families that Platform Graphs Cannot See
University of Tennessee, Knoxville（田纳西大学诺克斯维尔分校）
针对Git分叉导致代码度量膨胀的问题，提出基于全局共享提交关系的去分叉映射p2PFull，通过集线节点星编码和并行Louvain聚类构建项目来源图，并验证了跨平台分叉家族的发现。
2026-07-14 cs.SE
Utilizing Source Code Syntax Patterns to Detect Bug Inducing Commits using Machine Learning Models
本研究提出从源代码语法模式中提取特征来检测引入缺陷的提交，实验表明该方法在多种机器学习模型上提升了缺陷检测性能，并提供了更好的可解释性。
2022-12-07 cs.SE
Understanding Emotions of Developer Community Towards Software Documentation
开源项目的可用性促进了开发人员在广泛的项目上做出贡献和协作。因此，为此类开源项目做出贡献的开发人员社区也在增加。许多项目都涉及频繁更新和广泛重复使用。一个更新良好的文档有助于更好地理解软件项目，也有助于有效的贡献和重用。虽然软件文档在软件开发和维护过程中扮演着重要的角色，但它也存在着诸如不充分、不一致、可维护性差等问题，探讨开发人员对文档的看法有助于理解软件文档中普遍存在的问题背后的原因。它可以进一步帮助决定可以向开发人员社区提供的培训，以便为社会建立更可持续的项目。分析项目贡献者的情绪可以为理解开发人员的看法提供见解。因此，作为朝着这个方向迈出的第一步，我们分析了特定于软件项目文档的提交消息的情感。为此，我们考虑了GHTorrent数据集中998个GitHub项目的提交历史，并确定了10，996个提交对应于存储库的文档。此外，我们应用情感分析技术来获得对所选提交的提交消息中表达的情感类型的见解。我们观察到，大约45%的已识别提交消息表达了信任情绪。
2021-03-01 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
Empirical Study on the Characteristics and Evolution of AI-usage in GitHub Repositories: Evidence from Code Comments
Missouri University of Science and Technology（密苏里科技大学）；Drexel University（德雷塞尔大学）
通过分析35,361条提及AI的GitHub代码注释及后续提交，发现开发者主要用LLM实现代码，随后频繁重构、集成和修复，AI引用从代码生成转向知识支持和代码增强。
2026-06-05 cs.SE
Introducing Traceability in GitHub for Medical Software Development
本文针对医疗软件等安全关键系统在持续软件工程与 DevOps 范式下面临的需求到实现可追溯性挑战，提出在 GitHub 中引入可追溯性能力的方法，使开发人员在保持原有工作方式的同时自动生成满足监管要求的文档。
2021-10-25 cs.SE
Learning from Mistakes: Understanding Ad-hoc Logs through Analyzing Accidental Commits
本文通过分析意外提交和直播编码视频，研究开发人员使用临时日志的实践，收集27GB数据揭示其在异步函数中的使用倾向，为改进相关实践提供实证与数据集。
2025-04-17 cs.SE
Compilation of Commit Changes within Java Source Code Repositories
本文提出 JESS 方法，通过仅编译提交中修改的相关代码并自动推断存根，解决了 Java 项目中修复提交难以编译为字节码的问题，显著提升了漏洞补丁字节码的获取效率。
2024-07-25 cs.PL cs.SE
On Relating Technical, Social Factors, and the Introduction of Bugs
随着协作编码环境使软件项目更容易做出贡献，参与这些项目的开发人员数量不断增加。这种增加使得代码审查者更难处理有bug的贡献。像GitHub这样的协作环境提供了关于开发人员贡献的丰富数据源。这样的数据可以用于提取关于开发者的关于技术的信息（例如，他们的经验）和社会（例如，的相互作用）因素。最近的研究分析了这些因素对软件开发的不同活动的影响。然而，在这些因素与错误引入之间的关系方面仍有改进的余地。我们提出了一个更广泛的研究，包括来自不同领域的8个项目和6，537个错误报告，涉及五个技术因素，三个社会因素和错误的介绍。结果表明，技术和社会因素可以区分错误和干净的承诺。但是，技术因素比社会因素更具决定性。特别是，开发人员不遵守技术贡献规范的习惯和开发人员的提交缺陷与提交缺陷的增加有关。另一方面，项目的建立、开发者提交的所有权级别和社会影响力与引入错误的机会较低有关。
2020-04-07 cs.SE
Unusual Events in GitHub Repositories
在大型和活跃的软件项目中，让开发人员了解所有项目活动变得不切实际。虽然可能没有必要了解每个提交或问题，但可以说了解不寻常的提交或问题是很重要的。为了研究这一假设，我们在200个GitHub项目中识别出了异常事件，使用了一个全面的列表，列出了工件可能异常的方式，并要求140名负责这些事件或受这些事件影响的开发人员对相应信息的有用性发表评论。基于2,096个答案，我们确定了开发人员认为特别有用的不寻常事件的子集，包括大量的代码修改和不寻常的审查活动，以及这些答案背后原因的定性证据。我们的研究结果提供了一种方法，可以减少开发人员需要解析的信息量，以便在项目中保持最新的开发活动。
2018-04-30 cs.SE
Bridging the Gap: A Comparative Study of Academic and Developer Approaches to Smart Contract Vulnerabilities
本文通过比较学术与开发者在修复智能合约漏洞策略上的差异，揭示了实际开发中存在与学术文献不一致的漏洞处理方法，并识别出27种新型修复策略。
2026-01-12 cs.SE
DevRank: Mining Influential Developers In Github
随着社交编码越来越流行，了解开发人员的影响力可以使各种应用程序受益，例如新项目和创新的广告。然而，大多数现有的工作只集中在排名的非加权和同构网络中的有影响力的节点，这是不能够适当的重要性得分转移到真正的重要节点。为了对Github中的开发者进行排名，我们定义了开发者对吸引关注能力的影响，可以通过未来获得的关注者数量来衡量。我们进一步定义了一种新的方法DevRank，该方法通过根据用户行为（包括“提交”和“关注”）构建的异构网络的影响力传播来对开发人员进行排名。实验比较了DevRank与其他链接分析算法的性能，结果表明DevRank能够提高链接分析算法的排名精度。
2017-10-28 cs.SE cs.SI
Identifying Unmaintained Projects in GitHub
背景：开源软件在现代软件开发中的重要性越来越大。然而，人们也越来越担心这些项目的可持续性，因为这些项目通常由少数开发商管理，他们往往是志愿者。目的：在本文中，我们提出了一种方法来识别未积极维护的GitHub项目。我们的目标是提醒用户使用这些项目的风险，并可能激励其他开发人员承担项目的维护。方法：我们训练机器学习模型，根据一组关于项目活动的特征（提交、分叉、问题等）来识别未维护或稀疏维护的项目。我们通过129个GitHub项目的主要开发人员经验验证了该模型的最佳性能。结果：基于真实开源开发人员的反馈，所提出的机器学习方法具有80%的准确率和96%的召回率。我们还表明，我们的方法可以用来评估项目变得不维护的风险。结论：本文提出的模型可以被开源用户和开发人员用来识别不再积极维护的GitHub项目。
2018-09-11 cs.SE
How Do Software Developers Use GitHub Actions to Automate Their Workflows?
本文首次实证研究开发者对 GitHub Actions 的使用及其影响，发现采用者评价积极，但该技术会增加月度拒绝 PR 数并减少已合并 PR 的月度提交数。
2021-03-22 cs.SE
Mind the Gap: An Empirical Study of Synchronization Gaps, Delays, and Missed Opportunities in Software Forks
Nanyang Technological University（南洋理工大学）
本研究针对GitHub分支家族开展大规模实证研究，开发监控平台挖掘分支提交，发现同步悖论等关键结果，揭示分支开发同步的核心问题与原因。
2026-08-18 cs.SE
Newcomer OSS-Candidates: Characterizing Contributions of Novice Developers to GitHub
开源软件（OSS）项目吸引、接纳和留住任何新来者的能力对其生存至关重要。尽管有证据表明，新手开发人员加入社交编码平台（如GitHub）的人数激增，但他们的活动在多大程度上导致了OSS的贡献尚不清楚。阻碍，我们执行注册报告的协议，以研究“新来者OSS候选人”的活动，他是一个新的社会编码平台的新手开发人员，并打算以后加入OSS项目。使用GitHub作为案例平台，我们分析了171个确定的新OSS候选人，以描述他们的贡献活动。结果表明，新来的OSS候选者可能以基于软件的存储库为目标（即，66%），他们的第一个贡献主要与开发（提交）和维护（PR）有关。新手OSS-候选人不太可能练习社交编码，但最终会加入（即，30%定量，70%后续调查）的开放源码软件项目。此外，他们认为找到一种开始的方式是最具挑战性的障碍。我们的工作揭示了社交编码平台的新来者如何成为OSS贡献的潜在来源。
2022-04-06 cs.SE
When the Model Retires: An Empirical Study of LLM Migration in Open-Source Applications
Myongji University（明志大学）
本研究通过挖掘GitHub提交，实证分析开源应用中LLM模型退役后的迁移行为，发现82%的迁移发生在关闭日期后，且通告长度显著影响迁移时机，并发布了相关数据集。
2026-09-28 cs.SE
GitQ- Towards Using Badges as Visual Cues for GitHub Projects
GitHub托管数百万个软件存储库，方便开发人员以多种方式为许多项目做出贡献。大多数关于仓库的信息都是基于文本的，以star、fork、commits等形式出现。然而，愿意为GitHub上的项目贡献内容的开发人员通常会发现，由于GitHub上存在大量的仓库，因此选择合适的项目进行贡献或重用是一件很有挑战性的事情。此外，获取这些所需的信息往往成为一个繁琐的过程，因为人们必须仔细挖掘隐藏在存储库中的信息。为了减轻工作密集型的挖掘过程，研究人员提出了npm标记来概述与项目的构建状态相关的信息。然而，这些标记是静态的，并且将它们的使用限制在包依赖性和构建细节上。向存储库添加诸如标记之类的可视提示可能会减少开发人员的搜索空间。因此，我们提出了GitQ，以自动增加GitHub存储库，其中包含代表源代码和项目维护信息的徽章。将GitQ作为浏览器插件呈现给GitHub可以让使用GitHub的开发人员轻松访问它。基于UTAUT模型，GitQ由15名开发人员进行评估，以了解开发人员对其有用性的看法。我们观察到，15个开发人员中有11个认为GitQ在使用GitQ生成的视觉提示来识别正确的存储库集方面很有用。源代码和工具可以在GitHub上下载，网址是https：//github.com/gitq-for-github/plugin，演示可以在https://youtu.be/c0yohmIat3A上找到…
2022-05-02 cs.HC cs.SE
Identifying Experts in Software Libraries and Frameworks among GitHub Users
Federal University of Minas Gerais（米纳斯吉拉斯联邦大学）；Federal Institute of Minas Gerais（米纳斯吉拉斯联邦理工学院）
软件开发越来越依赖于库和框架来提高生产力并缩短上市时间。尽管如此，我们仍然缺乏技术来评估开发人员在广泛流行的库和框架中的专业知识。在本文中，我们评估了无监督（基于聚类）和有监督机器学习分类器（随机森林和SVM）的性能，以识别三个流行的JavaScript库中的专家：Facebook/react、mongodb/node-mongodb和socketio/socket.io。首先，我们收集了关于GitHub项目上开发人员活动的13个特性，包括依赖于这些库的源代码文件的提交。我们还建立了一个地面真相，包括575名开发人员对所研究的库的专业知识，正如他们在调查中自我报告的那样。基于我们的研究结果，我们记录了使用机器学习分类器来预测软件库中的专业知识的挑战，使用从GitHub提取的特征。然后，我们提出了一种方法来识别图书馆专家的基础上聚类特征数据从GitHub的三角形的结果与Linkedin配置文件上提供的信息，我们表明，它是能够推荐几十个GitHub用户的证据是专家在所研究的JavaScript库。我们还提供了一个公共数据集，其中包含575名开发人员对所研究的库的专业知识。
2019-03-19 cs.LG cs.SE
An Empirical Validation of Open Source Repository Stability Metrics
本研究针对开源软件供应链依赖度提升的背景，对基于控制理论提出的综合稳定性指数（CSI）开展首次实证验证，通过100个高排名GitHub仓库实验优化了采样方式与统计方法，为开源项目健康监控提供了实证支撑的应用方案。
2025-08-02 cs.SE
