An IEEE GitHub citation starts with the software version you used. Compare the repository's citation file with its release and archive record, then keep a recommended paper in its own reference when it supports a different claim.
Inspect the Repository's Citation Guidance
If you used code from GitHub in a paper, start with the repository's CITATION.cff file and its “Cite this repository” panel. The file can name the software's authors, title, release date, version, repository, and DOI. It can also request a citation to a related paper through preferred-citation. GitHub currently offers APA and BibTeX in its citation panel, so neither button gives you a finished IEEE reference.
I compared the citation file, release page, and archive record for OpenGeoSys, an open source simulation program. For this IEEE GitHub citation, the three records need to identify the same release. The authors are the people or group credited for the software in the project and archive metadata. The account name ufz identifies the GitHub owner; it does not make that account the only author.
| Place to check | Useful fields | Question it answers |
|---|---|---|
CITATION.cff | Authors, title, version, date, DOI, preferred-citation | How does the project ask to be credited? |
| GitHub release or tag | Version label, release date, tagged source revision | Which code did you run? |
| Zenodo or another archive | Creators, version, publication date, DOI | Does this identifier resolve to that release? |
Check the file at the tag you used when it is available. A citation file on the default branch may have been edited after that release. If there is no CITATION.cff, read the project's README, release notes, and archive record for explicit citation instructions. The website citation guide explains when an online source needs a software reference.
Identify the Release You Used
Write down the version from your environment, lockfile, installation log, or analysis notes. Then open the matching GitHub release. A link to a repository's main page can lead readers to different code months later. The OpenGeoSys 6.5.2 release is dated June 14, 2024. Its tag names the source revision presented as that release. The matching Zenodo record says version 6.5.2, gives the same publication date, links to that tag, and assigns DOI 10.5281/zenodo.11652195.
The records disagree on one field. The citation file stored at tag 6.5.2 labels itself version 6.5.2, yet its top-level doi is 10.5281/zenodo.10890088. That DOI opens the archive record for version 6.5.1. The 6.5.2 archive record supplies 10.5281/zenodo.11652195. Copying the citation file's DOI without resolving it would identify a different release.
| OpenGeoSys record | What it says | Use for a 6.5.2 citation |
|---|---|---|
| GitHub release | 6.5.2, Jun. 14, 2024 | Release identity and source link |
Tag's CITATION.cff | doi: 10.5281/zenodo.10890088 | Check the DOI target before using it |
| Zenodo version record | 6.5.2, DOI 10.5281/zenodo.11652195 | Version-specific archived identifier |
Zenodo also has a concept DOI for the OpenGeoSys series, 10.5281/zenodo.591265. It covers the collection of versions and currently resolves to the latest record. For a reproducible method section, choose the DOI for the release you actually used. If the repository has no archive DOI, keep the versioned GitHub release URL or a commit identifier so another researcher can find the same code. Record an access date when the source you cite is a changing online page and your target guide calls for one.
Separate Software From Its Associated Paper
A preferred-citation can point away from the software object. Julia's citation file asks users to cite a paper and supplies a preferred-citation of type article. Its DOI, 10.1137/141000671, resolves to “Julia: A Fresh Approach to Numerical Computing” in SIAM Review. That DOI identifies the article. It does not specify which Julia executable or source revision ran an analysis.
Follow the project's request when you discuss the published paper or need to credit the work as its authors ask. If your methods depend on a particular software build, identify that build as well. Whether your paper needs separate references for the software and the article depends on what each sentence is supporting and the instructions of your publication. Do not attach a journal DOI to a software-release entry or use a Zenodo software DOI as the article's identifier.
[n] J. Bezanson, A. Edelman, S. Karpinski, and V. B. Shah, “Julia: A fresh approach to numerical computing,” SIAM Rev., vol. 59, no. 1, pp. 65–98, 2017, doi: 10.1137/141000671.The article reference above has journal, volume, issue, and pages because those details belong to the published paper record. A software citation needs the program name, version, release date, repository or archive, and a locator for the software. The DOI lookup guide explains how to check that an identifier leads to the source named in your reference.
Assemble and Verify the IEEE Reference
IEEE's Reference Guide has a software section. For software used in a paper, it asks for authors, the software name, repository or archive, version, release date, and a unique identifier where available. Its basic pattern also allows a publisher, access date when applicable, medium, and URL. Use the available fields from the same release, then apply any narrower rule set by your journal, conference, or instructor.
[n] J. K. Author. Software Title. (Release date). Repository or archive. (version). [Computer software]. doi: version-specific DOI. Available: fixed release URL[n] D. Naumov et al. OpenGeoSys. (Jun. 14, 2024). Zenodo. (version 6.5.2). [Computer software]. doi: 10.5281/zenodo.11652195. Available: https://github.com/ufz/ogs/releases/tag/6.5.2This example uses the first creator and et al. because the archive lists more than six creators, following the IEEE guide's author rule. The reference number [n] stands for the number assigned by your manuscript. The release URL lets readers inspect the code; the DOI resolves to the archived version. If your venue wants the DOI as a full https://doi.org/ link, follow its instructions and keep the identifier attached to the same version.
This site currently has no dedicated software source type. A generic Website or Online entry can lose the release version and archive relationship, so finish a software reference manually against the IEEE guide. The BibTeX import guide also explains why an imported @software record needs source-type review rather than automatic acceptance. Use the final IEEE checklist when you place the finished entry in your paper.
Frequently Asked Questions
How do I cite a GitHub repository in IEEE style?
First identify what the repository contains and the version you used. For software, use its credited authors, title, release date, version, archive or repository, and a version-specific DOI or fixed release URL. Follow the IEEE software pattern and your publication's instructions.
Can I paste GitHub's BibTeX citation directly into an IEEE paper?
GitHub offers APA and BibTeX exports, not an IEEE-formatted line. BibTeX can supply fields for a bibliography workflow, but you still need to check its source type, authors, version, DOI, and final output.
Should I cite the GitHub owner as the author?
Use the creators credited for the software release or archive. A repository owner may be a person or organization that hosts the project, and its account label alone does not settle authorship.
Should I cite a concept DOI or a version DOI?
Use the version DOI when your methods rely on a particular release. Zenodo recommends it for reproducibility. A concept DOI can be useful when discussing the project across versions without tying a claim to one build.
Do I need both the software and its recommended paper?
Check what your text uses. A paper citation credits and locates that publication. A software citation identifies the program you ran. Include separate entries when both objects support your work, subject to the venue's instructions.