Identify what the reference is meant to identify
A GitHub repository may contain source code, data, documentation, issue discussions and continuous development. A link to its front page does not show which version produced a research finding. Decide whether the scholarly object is a software release, one code state, a data release or the project description. The methods section should separately explain how the object was used.
Look for CITATION.cff, a “Cite this repository” function, a DOI or preferred citation in the documentation. Check those details rather than copying them mechanically. Ensure the title, creators, version and date match the revision used. The authors of the software may not be the same people as the owner of the hosting account.
Prefer a release when it matches the executed code
A release wraps an identified state and often carries a comprehensible version such as 2.1.0. It is easier for readers to recognise than a long hash and may include source archives and release notes. Cite the release that actually ran in your analysis. A newer bug-fix release cannot silently replace it in the historical record.
Record the displayed version and release date and check that the tag points to the expected commit. For your own project, create a release only after testing the clean package and documenting dependencies. A GitHub tag improves version identification, but the development platform alone is not necessarily a long-term preservation service.
Use a commit for an unreleased or highly specific state
Active research may rely on a correction that has not reached a release. The full commit hash can then provide the most precise locator. Short hashes are convenient in discussion, but the full identifier is more robust in a citation. Add repository creators, title, year or date, host URL and access date according to the required style.
A commit fixes the repository contents, not the surrounding environment. Tie it to the input data, command and software environment record. A private repository may still be inaccessible to examiners; arrange an institutional submission or controlled archive rather than assuming a platform invitation will remain valid.
Pair development history with durable preservation
A research repository such as Zenodo can ingest a GitHub release, preserve metadata and issue a DOI. A DOI may identify one version, while a concept DOI points across versions. Reproducibility normally requires the version-specific record. On the archive page, verify that the package contains the release and commit expected.
Archiving requires clean metadata, a rights check and a licence. Remove credentials, personal information and non-distributable components before they enter public history. A permanent deposit is not a scratch directory that can be tidied later. When open release is not possible, a metadata record with a governed access route can communicate the boundary honestly.
Assemble a complete software reference
A useful record contains creator or project, software title, version, year, a software label where the style permits it, archive or platform, and DOI or stable URL. Add an access date where the style calls for it or the destination can change. For a particular code passage, the prose may state file and function; line numbers remain unstable unless the version is fixed.
A generic version example is: “Creator (Year). Software title (Version X.Y) [Software]. Archive. DOI.” For a commit: “Project team (Year). Repository title (commit: full hash) [Software]. GitHub. URL (accessed date).” Adapt punctuation and name order to the institutional style while preserving the identifying content.
Separate citation, method and licensing
The citation attributes and locates the software. The method describes installation, parameters, inputs and modifications. The licence sets the legal terms for reuse and distribution. None can stand in for the others. If you modified external code, cite the upstream project, identify your fork or patch and follow its notices and licence.
Before submission, test every reference while signed out. Does the DOI open the correct version? Do release, tag and commit agree? Is the cited object listed in the bibliography or software register and linked at the relevant method? Preserve the metadata with your thesis reproducibility package.