From GitHub to Zenodo: Make Your Code and Data Citable

You have finished an analysis. The scripts are on GitHub, the figures look right, and the manuscript is nearly ready. Then comes a small question: what should someone cite if they use your code?

A repository URL points readers to your project, but its default branch keeps changing. Zenodo preserves a released version and assigns it a Digital Object Identifier (DOI) that readers can cite and retrieve later.

This guide takes you from an existing GitHub repository to a checked, citable archive. The order matters: prepare the repository, connect it to Zenodo, publish a GitHub release, then verify the Zenodo record. An ordinary commit or a click on Sync now does not create a new archive.

1. Prepare the version you want to share

You need a GitHub account, a Zenodo account, and a public repository that you can administer. Creating a GitHub release requires write access; connecting the repository to Zenodo also requires the appropriate integration permissions. For an organization-owned repository, its owner may need to approve Zenodo. See GitHub’s Zenodo setup guidance.

Before releasing, check that the repository includes:

Commit and push your final changes to GitHub. Files saved only on your computer will not appear in the release. Remove credentials, private information, and anything you do not have permission to redistribute before making material public.

Add citation metadata before the release

A CITATION.cff file in the repository root can describe the software title, authors, ORCIDs, version, release date, and license. GitHub can display a Cite this repository option, and Zenodo can import the metadata. Use GitHub’s citation-file example and Zenodo’s supported CFF fields.

You can instead supply .zenodo.json for Zenodo-specific metadata. If both files exist, Zenodo uses .zenodo.json and ignores CITATION.cff for the import. Keep the chosen file current and include it in the version you release. Zenodo’s metadata guide explains the alternatives.

2. Link your GitHub account to Zenodo

Logging in to Zenodo, linking GitHub, and enabling a repository are separate checkpoints. Being logged in does not by itself enable archiving.

These steps follow Zenodo’s account-linking guide. Review the permissions Zenodo requests and why before authorizing access.

3. Enable the specific repository

Open the Zenodo GitHub integration page. You can also reach it through profile menu → GitHub. If the link takes you to a login screen, sign in and open it again.

Sync now refreshes the repository list. The switch enables release archiving for that repository. You must complete this step before publishing the release you want archived. Zenodo’s repository-enabling guide describes the same sequence.

Do not assume that enabling the integration will archive releases you published earlier. The automatic workflow processes new releases after connection. If a release already exists, see the troubleshooting section below.

Optional: share an unpublished draft for review

The GitHub integration is an automatic publication workflow. If coauthors need to review an unpublished Zenodo record, prepare a manual draft first. Publishing a GitHub release is not a private-preview step.

Treat the link as private: anyone who receives it can use it, and its permission can extend to later versions. Set an expiry or remove it through Share → Links when review is finished. See Zenodo’s link-sharing instructions and draft-sharing requirements.

Use Share for coauthor feedback. Zenodo’s Submit for review is a community-curator workflow that publishes the record when accepted.

Leave the record as a draft during review. A manual draft can reserve a DOI through Get a DOI now!, but it is registered only on publication. GitHub integration does not support pre-reserving its release DOI. A manual draft is not automatically connected to future GitHub imports, so choose one publication route after review and avoid duplicate records.

4. Create and publish a release on GitHub

A tag names a particular point in the repository’s history, such as v1.0.0. A release adds a public release page and notes to that tag. GitHub generates source-code downloads for the tagged version. See GitHub’s explanation of releases.

Find the release page

Open your repository’s main page on GitHub. To the right of the file list, select Releases, then Draft a new release. For a repository with no releases, GitHub may instead show Create a new release.

You can also append /releases/new to your repository URL:

Replace OWNER with the GitHub username or organization and REPOSITORY with the repository name. These are placeholders, not text to leave in the URL.

For a concrete example, the text-to-narration repository has a Releases page and a new-release form. The form requires sign-in and write access. Use the equivalent links for your own repository when following this guide.

Fill in the release form

The full UI reference is GitHub’s release-management guide. Your published release should now appear on the repository’s Releases page with its version tag.

5. Check the archive on Zenodo

Return to the Zenodo GitHub integration page and select the repository. Wait for the release to finish processing; the time depends on its size and Zenodo’s workload. Open the DOI link shown for that release.

On the record page, verify:

For a metadata correction, open your Zenodo record, select Edit, make the change, then Publish the update. Editing metadata does not change the DOI. Also correct the repository metadata file so future releases import the right information.

If processing fails, expand the failed release on the integration page and select Errors. Zenodo’s release-archiving guide shows where to find these details. Do not put a DOI into your paper until you have checked the record it identifies.

6. Archive supporting data deliberately

Small example datasets committed with the source can accompany the code archive. A README link to an external dataset does not preserve the files at that destination. Larger collections, or data that deserve their own citation, are often clearer as a separate dataset record.

For a separate dataset:

Follow Zenodo’s upload guide for field details. Records allow up to 100 files, with 50 GB of storage by default. For larger deposits, the draft’s Manage storage control can allocate available extra quota. Check Zenodo’s current storage limits before preparing a large deposit.

Using Git LFS? GitHub’s source archives contain LFS pointer files by default, rather than the large files themselves. An administrator can enable Settings → General → Archives → Include Git LFS objects in archives. Check GitHub’s LFS archive guidance, then inspect the actual Zenodo download. Do not assume that separately attached GitHub release files, submodule contents, external downloads, or LFS data are present without checking.

7. Choose the right DOI and keep it useful

Zenodo provides two identifiers for a versioned work:

See Zenodo’s DOI-versioning explanation. The record’s Citation panel supplies a ready-to-use citation, normally for the specific version; the Versions panel shows the concept DOI. Copy the appropriate identifier and check the authors, title, year, and version. Zenodo explains these controls in its sharing and citation guide.

Add a descriptive DOI link or badge to your README. Make clear whether it points to a particular version or the project across versions. If you update citation metadata after receiving the DOI, remember that a new GitHub commit does not change the already archived files.

For the next substantive revision, update the code, documentation, and version metadata, then publish a new release with a new tag, such as v1.0.1. Keep the repository enabled and check the resulting Zenodo version before using its DOI.

If something is missing or does not work

My repository does not appear in Zenodo

Confirm that it is public, that the correct GitHub account is linked, and that you have administrator access. For an organization repository, check whether its owner must approve Zenodo’s OAuth access. In GitHub’s authorized OAuth apps, open Zenodo and inspect Organization access. Then return to Zenodo and click Sync now. See Zenodo’s organization-repository troubleshooting guide.

I cannot find the release button

Use your repository’s /releases page or append /releases/new to its URL. Confirm that you are signed in to GitHub with write access. A page that only lists tags is not the new-release form.

I published a release but no DOI appeared

Check that the repository switch was on before publication, that you published a release rather than only creating a tag or saving a draft, and that processing has finished. Select the repository on Zenodo and inspect the release’s Errors. Invalid citation metadata may need correction before another release.

The release existed before I enabled Zenodo

Do not expect Sync now to backfill it. The documented automatic path is to enable the repository first and publish a new release. If you need to preserve that exact older version, use Zenodo’s manual software-upload guide with the correct tagged source archive and version metadata. A manual deposit is a separate workflow; do not assume it will be joined automatically to future GitHub imports. Check whether a record already exists before creating a duplicate.

Final check before citing

You should have a published GitHub release, a completed Zenodo record, a downloaded archive that contains the expected files, accurate metadata, and the version DOI for the work you actually used. That makes the citation useful to the next researcher who wants to reproduce your result.