Phrasit

Search Phrasit

Search every tool, guide, and citation page.

CITATION GUIDE 8 MIN READ

How to cite a GitHub repo or software (APA 7, MLA 9, Chicago, Harvard)

Software and GitHub repositories are cited like any creative work, but two extra fields carry most of the weight: the version you used and a persistent identifier. A reproducible citation names the author or maintaining organisation, the year, the project title, the exact version or commit, and a DOI or repository URL so a reader can run the same code you did.

Written by Vikas Dulgunde, Software EngineerUpdated How this is madeConnect on LinkedIn

Generate the citation now

Build a formatted reference and in-text citation in APA, MLA, Chicago, Harvard, or IEEE, then check it against the rules below before you submit.

Open the free citation generator

When to use this format

Use this format when you cite a software package, library, command-line tool, model, or research codebase, whether it lives on GitHub, GitLab, PyPI, CRAN, or an institutional archive. The author is the project's lead developer or the maintaining organisation, the title is the project name, and the version is essential because behaviour changes between releases.

Check the repository for a CITATION.cff file or a citation note in the README first, because many projects tell you exactly how they want to be cited and may provide a Zenodo DOI for a specific release. If a DOI exists, prefer it over a bare repository URL, since a DOI resolves to a frozen snapshot while a repository keeps changing.

What you need before you start

Collect these details from the GitHub repository or software itself, not from a search result or a reposted copy. Getting the fields right once makes every style format below fall into place.

  • Author or maintaining organisation, as credited in the repository or CITATION file.
  • Year of the version or release you used.
  • Project or software title.
  • Version number or commit hash.
  • A format label such as [Computer software].
  • A DOI when one exists, otherwise the repository URL.

Worked examples in four styles

The same facts appear in every style, but they move around and change punctuation. Match the reference-list entry and the in-text citation to the style your assignment requires.

APA 7

APA 7 names the authors or the organisation, gives the version in parentheses, adds [Computer software], and ends with a DOI or URL. Cite the version you used, not the latest release, because results depend on it.

Reference list

Pedregosa, F., Varoquaux, G., & Gramfort, A. (2024). scikit-learn (Version 1.5.0) [Computer software]. https://doi.org/10.5281/zenodo.591296

In text: (Pedregosa et al., 2024)

MLA 9

MLA names the developers, the title in italics, the version, the year, and GitHub as the container with the URL. For an organisation-maintained project with no lead author, start with the project name.

Reference list

Pedregosa, Fabian, et al. scikit-learn. Version 1.5.0, 2024. GitHub, github.com/scikit-learn/scikit-learn.

In text: (Pedregosa et al.)

Chicago

Chicago lists the developers, the year, the project, the version, and the language or platform, then the DOI or URL. A footnote can record the commit hash and access date for exact reproducibility.

Reference list

Pedregosa, Fabian, Gael Varoquaux, and Alexandre Gramfort. 2024. scikit-learn (version 1.5.0). Python. https://doi.org/10.5281/zenodo.591296.

In text: (Pedregosa et al. 2024)

Harvard

Harvard keeps the authors, year, title, version, and software label, and adds Available at with the DOI or URL plus an access date. Use the CITATION.cff author order when the project provides one.

Reference list

Pedregosa, F., Varoquaux, G. and Gramfort, A. (2024) scikit-learn (Version 1.5.0) [Computer software]. Available at: https://doi.org/10.5281/zenodo.591296 (Accessed: 15 January 2026).

In text: (Pedregosa et al., 2024)

Judgement calls and edge cases

Version is not optional for software. A package at version 1.5 can behave differently from version 2.0, so a citation without a version number does not let anyone reproduce your work. When a release has no clean version tag, cite the commit hash instead, because it pins the exact state of the code you ran. This matters most in research where a reviewer must be able to repeat your analysis.

Always look for a CITATION.cff file or a How to cite section before you hand-build an entry. Maintainers use these to request a specific author order, a specific DOI, and sometimes an associated paper they would rather you cite alongside the software. Following that request is both correct and good etiquette, and it usually gives you a more stable reference than a repository URL.

Distinguish the software from the paper that describes it. Some projects want you to cite a published article for the method and the software separately for the implementation. If the repository points to a companion paper, cite both: the paper for the idea and the code for the exact tool, each with its own entry, so credit and reproducibility are both covered.

Common mistakes

  • Omitting the version number or commit hash.
  • Citing a repository URL when the project provides a DOI for the release.
  • Ignoring the CITATION.cff file and inventing your own author order.
  • Using the year you accessed the code instead of the release year.
  • Citing only the software when the project also asks you to cite its paper.

Source notes

Citation rules vary by edition and discipline, and platforms relabel and remove content over time. These references are useful starting points for the current published rules:

Related guides