GitHub for accounting researchers
In July 2021, a retraction notice in the Journal of Finance reported that “the original data and code that produced the published results were lost.” The natural response is: if only the authors had used GitHub.
There is something to this response, but opening a GitHub account does not make research reproducible. GitHub cannot preserve code that never makes it into a repository, and preserving code does not establish that the code produces the results in a paper. The more useful question is how GitHub might fit into a research workflow in which losing the code, or losing track of which code produced which results, becomes much less likely.
What is GitHub?
Git is software for tracking changes in files. GitHub hosts Git repositories and provides tools for collaboration around them. There are alternatives to GitHub, including GitLab and Bitbucket, but I will focus on GitHub here.
Git is particularly useful for text files: code for your favourite statistical package, LaTeX source, Markdown documents, and configuration files. A commit records a version of those files along with a message explaining the change. The resulting history lets you inspect changes, compare versions, and return to an earlier state of the project. Pushing commits to GitHub makes that history available beyond your own computer.
These features are useful even if you work alone. They become more useful when several people are changing code and text, trying alternative analyses, and wondering which version of a table belongs in the paper.
Some case studies
Here are some ways I had used GitHub when I first wrote this note in 2021. These are examples, rather than a claim to best practice.
The code and text for Causal Inference in Accounting Research are available in a public repository. The repository brings together the LaTeX source and the analysis code, and its history records earlier versions of the paper. On this project, my two co-authors worked on the paper using Overleaf. I managed the GitHub side of the project using Overleaf’s integration with GitHub. My co-authors could continue using their preferred editor while the project benefited from version control.
Non-Answers During Conference Calls, co-authored with David Larcker and Anastasia Zakolyukina, was also managed using GitHub. Some analysis code was kept in private repositories, while other elements were made public. For example, the performance analysis of the paper’s core measure is available in a public repository.
Related to that paper, the core measure was made available in the Python package ling_features. Its GitHub repository provides a place for others to inspect the code, report problems, and suggest changes through pull requests. A research project can thus produce something that other researchers can use and improve, rather than a collection of files that remains untouched after publication.
I also used a private repository to manage data obtained through an institutional subscription to WhaleWisdom, together with the code used to update those data. This made it easier to share work with authorised colleagues and return to earlier versions when necessary. That example does not mean that all research data belong in Git. Large data sets often belong elsewhere, and access arrangements must follow the data licence. The important connection is between a version of the code and the particular data on which it was run.
In 2021, I was writing a book for an introductory course on accounting research. The book’s source was maintained using GitHub, while a separate public repository for the FARR R package held data and code for readers. This separation made it possible to develop the book and provide reusable materials alongside it.
Finally, starting with the SAS and Stata code and data supplied by Fang, Huang, and Karpoff (2016), I reproduced their analyses using R. The archived replication repository illustrates a straightforward use of GitHub: make the code behind a replication available for others to inspect and run.
Learning the workflow
There is a learning curve. Terms such as commit, branch, and merge are unfamiliar at first, and resolving a conflict between two people’s edits can be frustrating. Starting with a small project is easier than introducing Git halfway through a complicated collaboration.
The broader benefit is a change in how research is organised. Code, data documentation, and the paper become parts of a project with an inspectable history. Others can build on the work, identify errors, and propose improvements. That is a useful foundation for the kind of replication and correction that helps a literature accumulate knowledge.