识别GitHub上的异常提交.pdf资源-CSDN文库

185 浏览量 2024-05-08 13:37:39 上传评论收藏 898KB PDF 举报

资源推荐

资源详情

资源评论

JOURNAL OF SOFTWARE: EVOLUTION AND PROCESS

J. Softw. Evol. and Proc. 0000; 00:2–35

Published online in Wiley InterScience (www.interscience.wiley.com). DOI: 10.1002/smr

Identifying Unusual Commits on GitHub

Raman Goyal

∗1

, Gabriel Ferreira

, Christian K

astner

and James Herbsleb

Indian Institute of Information Technology, Allahabad

Carnegie Mellon University

SUMMARY

Transparent environments and social-coding platforms as GitHub help developers to stay abreast of changes

during the development and maintenance phase of a project. Especially, notiﬁcation feeds can help developers

to learn about relevant changes in other projects. Unfortunately, transparent environments can quickly

overwhelm developers with too many notiﬁcations, such that they loose the important ones in a sea of

noise. Complementing existing prioritization and ﬁltering strategies based on binary compatibility and code

ownership, we develop an anomaly-detection mechanism to identify unusual commits in a repository, that

stand out with respect to other changes in the same repository or by the same developer. Among others, we

detect exceptionally large commits, commits at unusual times, and commits touching rarely changed ﬁle

types given the characteristics of a particular repository or developer. We automatically ﬂag unusual commits

on GitHub through a browser plugin. In an interactive survey with 173 active GitHub users, rating commits

in a project of their interest, we found that, though our unusual score is only a weak predictor of whether

developers want to be notiﬁed about a commit, information about unusual characteristics of a commit change

how developers regard commits. Our anomaly-detection mechanism is a building block for scaling transparent

environments. Copyright

 0000 John Wiley & Sons, Ltd.

Received . . .

KEY WORDS:

software ecosystems; notiﬁcation feeds; information overload; transparent environments;

anomaly detection

 0000 John Wiley & Sons, Ltd.

Prepared using smrauth.cls [Version: 2012/07/12 v2.10]

1. INTRODUCTION

Collaborative development in open source, software ecosystems, and also industrial software systems

relies increasingly on decentralized decision making [17, 20, 27, 41]. Interdependent components

evolve independently and often with little explicit collaboration. Backward-incompatible changes

that break modularity and produce rippling effects on downstream components are often necessary to

avoid opportunity costs (not ﬁxing mistakes, stiﬂing change in the face of evolving requirements) and

common in practice [10, 14, 19,25, 29, 35, 38

–

40, 43, 47]. In addition, components may change to add

new functionality that developers might want to adopt. Identifying relevant changes and reacting to

them if needed can create a signiﬁcant burden on developers during maintenance [3,4,6,24,35,42,47].

Seeds of a solution can be found in today’s transparent environments or social-coding platforms

such as GitHub, LaunchPad, and Bitbucket. These environments provide mechanisms for notiﬁcation

and exploration, that help developers to stay abreast of activities across collections of projects

without central planning [11, 12]. For example, on GitHub, developers can watch projects and receive

a notiﬁcation feed of activities in watched projects, such as push events or bug reports. These tools

work well at small scales, but break down for large projects where imprecise and insufﬁciently rich

notiﬁcation mechanisms lead to information overload from notiﬁcation cluttering. By inspecting

publicly available events on GitHub, we found that active developers typically receive dozens of

public event notiﬁcations a day and a single active project can produce over 100 notiﬁcations per

day (and many more when including notiﬁcations of indirect dependencies). When we previously

interviewed active GitHub users, many reported drowning in change notiﬁcations, for example

stating “I stopped with the email – now I use the GitHub notiﬁcations page. And the volume is a

problem” and “I just wander through GitHub activity streams occasionally. [But] it is very much

a crap shoot to actually get useful information from the feed” [3, 11].

∗

Correspondence to: Journals Production Department, John Wiley & Sons, Ltd, The Atrium, Southern Gate, Chichester,

West Sussex, PO19 8SQ, UK.

 0000 John Wiley & Sons, Ltd. J. Softw. Evol. and Proc. (0000)

Prepared using smrauth.cls DOI: 10.1002/smr

A key to scale transparent environments is to identify relevant notiﬁcations and route them to

affected or interested developers. There are many possible reasons why a change might be relevant

for a developer, including the following explored in prior work:

•

Identify breaking changes: Typically most changes are backward compatible. Notiﬁcations

about the rare breaking changes are of especial importance to maintainers of affected

downstream projects. Continuous integration platforms can help to highlight changes that

break the system. In addition, Holmes and Walker designed a system that statically detects

certain incompatible interface changes in Java to ﬁlter notiﬁcations correspondingly [24].

•

Identify critical ﬁxes to vulnerabilities: Patched vulnerabilities in upstream projects are typically

of high importance to update the dependency to a newer version. The service Gemnasium

tracks dependencies among Ruby packages and notiﬁes registered package maintainers if an

upstream dependency has a known vulnerability (CVE). In addition, several simple heuristics

and learning approaches can identify bug ﬁxing commits [22,55].

•

Identify relevance based on prior activity: In large code bases, developers may be interested

only in notiﬁcations about code that relates to their own activities, such as notiﬁcations

about changes in code that they have written. Padhye et al. model relevance based on simple

heuristics regarding prior modiﬁcations, code ownership, and commit messages to similarly

reduce information overload [42].

In this paper, we explore a different, complementary strategy to identify another class of relevant

notiﬁcations:

•

Identify unusual changes: We identify changes that are unusual or stand out with respect to

other changes in the repository. For example, commits that are particularly large, changes to

artifacts in a programming language not commonly used in the project or by that developer, or

changes with exceptionally long commit messages might be worth noting. We developed an

programming-language-independent anomaly detection mechanism that identiﬁes outliers with

regard to other changes in the same repository or other changes by the same developer.

 0000 John Wiley & Sons, Ltd. J. Softw. Evol. and Proc. (0000)

Prepared using smrauth.cls DOI: 10.1002/smr

We detect outliers using statistical models capturing common characteristics of commits within a

project or by a developer. Based on those models, we provide an anomaly score for each commit. The

anomaly score can be used to prioritize and ﬁlter notiﬁcation feeds, in concert with other detection

approaches, such as detecting breaking changes. In addition, anomaly scores can highlight unusual

commits in the revision history to support exploration and inspection and to point out unusual

characteristics during code reviews to focus the reviewer’s attention. We implemented a prototype

of our anomaly detection mechanism and provide a frontend through a browser plugin that injects

anomaly scores, including an explanation, into the commit history on GitHub pages.

In an evaluation, we analyze to what degree our model can predict changes developers will identify

as unusual and to what degree we can identify commits about which developers want to be notiﬁed.

We design an online survey with which participants rated commits in a repository of their choice. In

each selected repository, we select ﬁve random commits with different anomaly scores (stratiﬁed

sampling) and ask participants whether they judge the commit as unusual and whether they would

want to be notiﬁed. We found that our unusual score only weakly reﬂects our participants’ notion

of unusualness and is also only a weak predictor of whether developers want to be notiﬁed (to be

expected as we capture only a subset of characteristics of important commits), but we also found

that information about unusual characteristics about commits are actionable. When provided with

additional information about why a commit is a statistical outlier, participants often revisited their

position and identiﬁed commits as relevant for a notiﬁcation.

Overall, we make the following contributions: (1) We design an anomaly model based on commit

characteristics to identify unusual commits in a repository and by a developer. (2) We tailor statistical

learning methods to build such models for Git repositories. (3) We integrate anomaly scores and

explanations into the GitHub web page using an implementation based on a browser plugin. (4) We

design an experimental setup to learn about the importance of unusual commits in a repository of the

participant’s choice. (5) We evaluate our anomaly model with 173 GitHub developers, showing that

despite weak predictive power, information about statistical outliers is actionable.

 0000 John Wiley & Sons, Ltd. J. Softw. Evol. and Proc. (0000)

Prepared using smrauth.cls DOI: 10.1002/smr

2. INDICATORS FOR IMPORTANT COMMITS

There are many reasons why a commit might be considered ‘unusual’ or important. In this work,

we refer to commits as unusual if they are statistical outliers according to some criteria, such

as commits that are substantially larger or were committed at an unconventional time of day. We

intentionally used a broad and subjective term to cover a wide range of different outlier characteristics.

Our mechanism is ﬂexible enough to incorporate additional characteristics and select and weigh

characteristics depending on developer preferences.

As part of a presurvey of our evaluation, which includes demographic questions about the

participants’ experience and knowledge about the selected repository, we asked our participants

(professional and academic GitHub users, see Sec. 4 for details) two open questions:

•

Some commits stand out among all commits in a repository. What characteristics make commits

stand out?

• What kind of commits do you usually pay attention to?

With both questions, we elicit commit characteristics that developers use to distinguish important

commits from unimportant ones.

Among our participants, the following indicators for important commits were very commonly

mentioned (at least by 30 developers):

•

Commits that introduce new features (often associated with feature requests); for example, one

participant claimed interest in “commits that adds nice features to the project.”

•

Commits that signify major development steps, usually related to merging, milestones, and

releases.

•

Commits that are large in size (in terms of lines of code or ﬁles changed); for example, one

participant wrote that changes stand out if they include “extensive changes, lots of churn.”

• Commits that ﬁx bugs or security issues.

•

Commits that change code about which the developers have particular knowledge or that could

affect their current tasks (code ownership, dependencies).

 0000 John Wiley & Sons, Ltd. J. Softw. Evol. and Proc. (0000)

Prepared using smrauth.cls DOI: 10.1002/smr

剩余34页未读，继续阅读

评论收藏

内容反馈

百态老人

粉丝: 1664
资源: 2万+

识别 GitHub 上的异常提交.pdf

最新资源

识别 GitHub 上的异常提交.pdf

GitHub入门与实践.pdf

与 Github Actions 持续集成.pdf

GitHub Business Model Analysis GitHub 商业模式分析.pdf

BlazeMeter 和 Github 操作 一体化.pdf

Qualys IaC 与 GitHub 的安全集成.pdf

分享github开源项目.pdf

Git 有多糟糕？表征秘密泄漏 在公共 GitHub 存储库中.pdf

com.github.LuckSiege.PictureSelectorpicture_libraryv2.1.1'

Github workflow Github 工作流程.pdf

GitHub.com.ISO.27001.Certification.pdf

GitHub协同开发指南.pdf

GitHub For Dummies.pdf

萌新也能学会的简单易懂github提交.pdf

开源GitHub权威介绍GotGitHub.zip

github镜像网站.pdf

超详细Github Desktop教程.pdf

github泄露监控实践.pdf

相关实用应用程序（Windows可用）

免费可用的ChatGPT网页版.zip

ChatGPT使用总结：150个ChatGPT提示词模板（完整版）

chromedriver-win64.zip

全国计算机二级WPSoffice精选350道选择题题库（含答案）.pdf

李飞飞自传 我看见的世界 The World I see

农村公交与异构无人机协同配送优化

哈尔滨工业大学-ChatGPT调研报告-2023.3.6-94页.pdf

4个亲测好用的ChatGPT4渠道

基于LSTM的财务因子预测选股模型.zip

基于LSTM的多因子选股策略.zip

最新资源

BlazeMeter 和 Github 操作一体化.pdf

Git 有多糟糕？表征秘密泄漏在公共 GitHub 存储库中.pdf

李飞飞自传我看见的世界 The World I see