How to Choose a Code Repository for Your Research

By Dr. Zubair Khalid, DVM, MS, PhD · 2026-11-11

A development repository is a workspace where you and your collaborators keep changing code, while an archival repository is a permanent, citable home for a frozen version of that code, and the best code repository for research is usually a pair of them rather than a single service. The working rule of thumb is simple. Write and version your code on a Git hosting service such as GitHub or GitLab, then deposit a tagged release of the exact version behind your paper in an archival repository that issues a persistent identifier, such as Zenodo, OSF, figshare, or your institution's own repository. If you remember nothing else, remember this: papers should cite archival copies, not links that can change or disappear.

This guide explains the main code repository options for research, the pros and cons of each, the criteria that actually decide the choice, three worked scenarios, and a reproducibility checklist you can apply before you submit a manuscript.

Why the repository choice shapes reproducible research

Reproducible research means that another person can rerun your analysis on your data and obtain your published numbers. In computational fields, that requires three things to survive together: the data, the code, and enough documentation to connect them. A plain journal article documents a study only partially if the underlying algorithm is described in words but the code itself is never provided, which is why sharing data and code is increasingly treated as part of the publication itself rather than an optional extra [1].

The measured picture across disciplines is sobering. In a review of prominent biomedical journals, only about 36 percent of manuscripts shared raw data and only about 9 percent shared code [2]. A separate analysis of 453 biomedical manuscripts published between 2016 and 2021 found that 50.1 percent failed to share their analytical code, and only about one in ten articles organized their code in a structured, reproducible way [3]. In a large audit of more than 1,000 survey-based social science articles, only about 35 percent of authors shared code, and roughly one in six published results was exactly reproducible, with failure traced mostly to unavailable, poorly documented, or incomplete code [4]. Even in radiology artificial intelligence research, 34 percent of 218 articles shared code but only 11 percent of all articles shared code that could actually reproduce results [5].

These gaps matter because journals increasingly ask for code, yet enforcement lags. As of 2012, only 22 percent of a reference set of 170 journals had any code sharing policy, though that figure had grown 30 percent in a single year [6]. A decade later, only 9.1 percent of 931 high-profile medical journals mandated data and code sharing with an availability statement, and among articles that declared code publicly shared, 39 percent of the deposited materials were unreachable when checked [7]. In aging research funded by the Nathan Shock Centers, 92 percent of 400 articles had no code availability statement at all, and only 6 percent pointed to a code repository [8]. The lesson for you as an author is that a vague sentence like "code is available from the corresponding author on reasonable request" often fails in practice, and a real, persistent, versioned repository deposit is what makes your availability statement true.

There is also a direct benefit to you. Authors who share data and code gain citations, visibility, and reuse of their methods, and the effort required is now comparatively small given the tools available [1]. Sharing code during peer review can additionally let reviewers verify analyses rather than take them on faith, which strengthens the manuscript before it is even published [9].

Two meanings of "repository," and why confusing them causes problems

The word repository covers two different kinds of infrastructure, and many availability statements fail because authors treat them as interchangeable.

A development repository is a Git hosting service. Git is a version control system that records every change you make to a project, so you can return to any earlier state and see who changed what. Services such as GitHub, GitLab, and Bitbucket host Git repositories and add collaboration features like issues, pull requests, and continuous integration. These services are excellent for daily work. Their weakness is longevity. URLs can be renamed, accounts can lapse, private repositories can vanish, and nothing assigns your code a stable scholarly identifier.

An archival repository is a service designed for preservation and citation. Examples include Zenodo, the Open Science Framework (OSF), figshare, and domain repositories run by institutions or consortia. These services assign persistent identifiers, most commonly a digital object identifier (DOI), which is a permanent string that resolves to your deposit even if the underlying hosting changes. Archival repositories keep a snapshot of your files at the moment of deposit and usually let you version updates without overwriting the original. They are the right target for the citation in your paper.

The scholarly consensus, echoed in analyses of code sharing practices, is that code should be properly described, archived, and referenced with persistent unique identifiers so that the link between a paper and the exact code version lasts [10]. Meta-research studies that checked declared shares found that materials could not always be located, which is precisely the failure mode that persistent identifiers are designed to prevent [7] [8].

Code repository for research options, compared

The table below is the core of this article. It compares the options you will realistically choose among when deciding how to share research code.

A short clarification on the last row. Large biological pipelines are sometimes shared in specialized repositories rather than general-purpose ones. The WARP project, for example, hosts cloud-optimized workflows for biological data processing in a GitHub repository, with semantic versioning, testing, and documentation, alongside a companion repository of Docker containers, and makes the pipelines exportable through Dockstore and importable into analysis platforms [11]. This shows how a development repository and a distribution channel can work together for compute-heavy biology.

The options explained on their own terms

GitHub

GitHub is the most widely used Git hosting service in research, and it is the default answer to "where do I put my code while I work on it." Its strengths are a mature interface, ubiquitous familiarity among collaborators and reviewers, free public and private repositories, and deep integration with the rest of the research tooling ecosystem. Large open projects in biology, such as the WARP pipelines described above, demonstrate that GitHub can serve as the public face of a serious, versioned, documented codebase [11].

The pros are community standard tooling, effortless collaboration, and a low barrier for newcomers. The cons are that GitHub itself is a commercial platform, that repository URLs are not permanent scholarly identifiers, and that a repository can be deleted, renamed, or made private at any time. That is why GitHub is best paired with an archival deposit rather than used alone as the citation target for a paper.

GitLab and self-hosted options

GitLab offers the same core version control functions with an important difference: it can be self-hosted by your university or institute. Some institutions run their own GitLab instances precisely because they want code under institutional control. The pros are flexibility, integrated continuous integration tools, and institutional ownership of the copy. The cons are a smaller research community than GitHub and the possibility that a small self-hosted instance outlives neither the server nor the sysadmin. If your institution runs one, it can also serve as a sensible private staging area before a public release, which aligns with the recommendation that an ideal code repository should be managed by the institution and accessible to everyone [12].

Zenodo

Zenodo is an archival repository operated under the CERN open science program that accepts files of many types, including software, and issues a DOI for each deposit. Its best-known research feature is integration with GitHub: you can connect a GitHub repository so that each tagged release is automatically copied into Zenodo and given its own versioned DOI. This pairing has become the standard pattern for citing code in papers. The pros are permanent identifiers, versioned DOIs, free hosting, and acceptance of large and varied file types. The cons are that Zenodo is not a development environment, has no issue tracker, and is intended for snapshots rather than live collaboration.

OSF

The Open Science Framework is a project-oriented repository built by the Center for Open Science. Where Zenodo is essentially a deposit box, OSF behaves like a project workspace that can hold code, data, preregistrations, and manuscripts together, with granular privacy controls and DOIs for key components. The pros are its structure for whole projects, strong privacy toggles, and the ability to keep components private during a blinded review and flip them public at acceptance. The cons are that it is less natural for line-by-line code development, since it does not replace Git, and that collaborators still usually need a real version control workflow behind the scenes.

figshare

figshare is a general-purpose archival repository that issues DOIs for individual research outputs, including software. The pros are simplicity and clean citability. The cons are that it is less software-aware than Zenodo, meaning fewer features aimed at code, and that it behaves like a deposit rather than a workspace. It is a reasonable choice when you need a DOI for a small, finished code artifact and your workflow does not revolve around Git releases.

Institutional and domain repositories

Many universities now run repositories that accept software deposits, and funders increasingly expect deposits in recognized repositories. An institutional repository is attractive because staff can help with metadata, licensing, and long-term curation, and because the institution has a stake in preservation [12]. Domain repositories, such as Dockstore for computational workflows, add field-specific value like container registries and platform import [11]. The cons are that institutional repositories vary widely in software support, and domain repositories serve only their niche.

Journal supplementary material

Depositing code as supplementary files with the manuscript is possible but weak. Supplementary material usually has no separate persistent identifier for the code, no version history, and no way to record updates. The policy literature shows journals have historically been slow even to require code sharing, so supplementary-only deposits tend to be the floor rather than the goal [6] [13]. Use it only when the journal rejects external links.

The criteria that decide real choices

When researchers weigh code repository for research pros and cons, six criteria separate defensible choices from defaults picked by habit.

1. Persistence and citability. Will the deposit still resolve in ten years, and can your paper cite it unambiguously? Archival repositories with DOIs win here, and this is the criterion most strongly emphasized in recommendations that code be archived and referenced with persistent unique identifiers [10]. A GitHub link is convenient but not permanent.

2. Version control fidelity. Can you record the history of changes and recover the exact version that produced a given result? Git-based services are unmatched here. A reproducibility audit found that reproducibility failure stems mostly from unavailable, poorly documented, or incomplete code, which makes intact version history one of your best defenses [4].

3. Access control and privacy. Can you keep work private during blind peer review, or restrict access to sensitive material? OSF and self-hosted GitLab are strong here, and GitHub private repositories work for the development phase. Note that privacy requirements extend to data as well as code. Health research, for example, faces privacy frameworks that constrain what can be openly shared, which is a recognized reason some health research code and applications remain narrow in scope [14]. When data cannot be shared raw, practical tools exist for anonymization, including platforms that implement masking, pseudonymization, and k-anonymity with low technical barriers [15].

4. Size, file types, and software metadata. Archival repositories differ in what they accept. If your deposit includes containers, large model weights, or reference data, check limits before you commit to a platform. Specialized repositories handle containers and workflows better than general ones [11].

5. Ecosystem and audience. Your collaborators, reviewers, and field's conventions matter. In some fields GitHub is the lingua franca, in others domain repositories dominate. Analyses of sharing practices show clear disciplinary differences in which repositories authors choose and how often they share at all [10], so matching local norms reduces friction.

6. Journal and funder compliance. Check the specific policy of your target journal and funder. Journal data and code policies vary widely in stringency, and higher-impact journals have been more likely to adopt open policies [6] [13]. Meeting the strictest plausible requirement, an archived DOI-linked deposit with a license, satisfies nearly every softer policy automatically.

Worked scenarios

Scenario 1. A graduate student in computational biology submitting a methods paper. She develops her analysis in R on GitHub from day one, using the workflowr approach that combines version control through Git, literate programming through R Markdown, automatic reproducibility safeguards, and a browsable website of results that she can share with her advisor by URL [16]. When the manuscript is accepted, she tags release v1.0.0, connects the repository to Zenodo, and cites the versioned DOI in the availability statement. This satisfies persistence, versioning, and citability simultaneously, and it is the pattern most reviewers now expect.

Scenario 2. A lab sharing a pipeline that collaborators in clinical medicine cannot fully open. A team processes sensitive cohort data and cannot release raw inputs. They publish the pipeline code openly on GitHub with a Zenodo DOI, document exactly which inputs are required, and use a low-code anonymization platform to prepare a de-identified demonstration dataset that preserves data utility without exposing personal information [15]. The availability statement distinguishes the openly shared code from the access-controlled data and explains the reason, which addresses the documented problem that some declarations of sharing lead to unreachable or restricted materials [7].

Scenario 3. A small team at an institution with a funder mandate. A two-person group must comply with a funder requiring deposits in recognized repositories. They use their university's GitLab for private development, since the institution-managed repository is accessible to everyone at the institution and aligns with the recommendation that repositories be institutionally managed [12]. At submission time they export the final code and the curated output files to the institutional repository, which assigns DOIs, and they also mirror the code release on Zenodo for external citability. Redundant archiving is cheap insurance against any single service changing terms.

A reproducibility checklist before you share

Use this list as a gate before your manuscript goes out. Each item maps to a documented failure mode in the audits described above.

1. The exact code version that produced every figure and table is archived in a repository that issues a persistent identifier, not just linked from a mutable page [10].
2. The repository states the software environment, including language version and package dependencies, so a stranger can reconstruct the setup.
3. A README explains how to run the analysis from raw or example input to final result, in order.
4. Data needed to rerun the analysis are either included, linked from a data repository, or the restriction is explicitly justified, since unjustified refusals to share are a documented, common problem [7].
5. The code is organized in a structured way rather than as loose scripts, because only about one in ten shared-code articles currently meets this standard [3].
6. Every decision in data cleaning and sample selection is reported transparently, for example through annotated workflow code, which is one of five formal recommendations for improving code reproducibility in medical research [12].
7. A license file is present so readers know what they may legally do with your code.
8. If a colleague cloned the repository cold, could they run it? Peer code review before release is itself a recommended practice, and structured code review checklists exist for this purpose [12].
9. The DOI in your availability statement resolves, and you have verified it in a private browser window, because a substantial fraction of declared shares turn out to be unreachable when audited [7] [8].
10. The repository link and DOI are recorded in your data management plan and lab notebook, so the next student can find them after you leave.

Common Mistakes and Limitations

Citing a live GitHub link instead of an archived DOI. This is the single most common error. The link works today and is dead in three years. Archive the release with a DOI and cite that.

Writing "available on request" without a plan to honor it. Meta-research consistently finds that availability statements are frequently not honored, with authors non-compliant with their own stated commitments and journals rarely verifying deposits [10] [7]. If you write it, you must maintain it.

Dumping the whole project folder without structure or documentation. Sharing is not the same as reproducibility. In the social science audit, most reproducibility failures came from code that was shared but incomplete or poorly documented [4]. Ten minutes of README writing changes the outcome.

Assuming a private repository is a safe long-term archive. Development services can change terms, and accounts lapse when people change jobs. Private storage protects nothing if no one can access it after you depart.

Ignoring the data side. Code without data cannot reproduce anything. Note the asymmetry in the literature: open data policies historically led open code policies, and journals remain further along on data than code [6]. Address both.

Overpromising in the other direction with sensitive data. Protected health information and similar material are governed by privacy frameworks that legitimately restrict open sharing [14]. Anonymization or controlled access is a valid and expected response, provided the restriction is stated openly rather than hidden.

Assuming your journal will catch problems. Enforcement is weak. Even among journals that mandate sharing, most lack mechanisms to verify authenticity, and many allow publication despite invalid sharing [7]. The responsibility for a working deposit is yours.

One limitation of the evidence itself. The audit numbers cited here come from specific journals, fields, and time windows, so they describe broad patterns rather than guarantees about any single venue or manuscript. Individual cases, especially those involving human subjects data, always need review under your institution's privacy and ethics requirements.

Frequently Asked Questions

What is the best code repository for research?

There is no single best one, because development and archiving serve different jobs. The strongest general pattern is GitHub or GitLab for active development, paired with Zenodo, OSF, or an institutional repository for the archived, DOI-cited release. Choose based on persistence, version control, privacy needs, and your journal's policy rather than on brand loyalty.

Can I just link to my GitHub repository in my paper?

You can, but you should not stop there. A plain link is not a persistent identifier, it can break if you rename or delete the repository, and audits show that declared links are sometimes unreachable. Tag a release, archive it with a DOI through a service such as Zenodo, and cite the DOI.

Do I need to share code if my journal does not require it?

Sharing is strongly in your interest even when optional. Only a minority of journals mandate code sharing, yet shared and verified code builds trust, invites reuse, and supports the broader shift toward reproducible research that journals and funders are actively encouraging [1] [6].

What is the difference between GitHub and Zenodo?

GitHub is a development platform built around Git version control, collaboration, and continuous integration. Zenodo is an archival repository that assigns permanent DOIs to frozen deposits. The two connect: each tagged GitHub release can be mirrored to Zenodo with its own versioned DOI, giving you live development and permanent citation in one workflow.

How should I handle code connected to sensitive or protected data?

Keep the code open where possible and the data controlled. State clearly in your availability statement what is restricted and why, since unexplained refusals are a documented weakness of current practice. Where data must be shared, consider established anonymization methods such as masking, pseudonymization, and k-anonymity, which low-code platforms now make accessible without advanced programming skills [15].

Should I make my repository public during peer review?

Yes, when the journal allows it and the material is not confidential. Sharing code during peer review lets reviewers check the analyses rather than trust the text, and it can catch problems before publication [9]. If blinded review prevents it, use a private repository or an OSF component you can reveal to the editor, then archive publicly with a DOI at acceptance.

Sources

1. Sharing data and code facilitates reproducible and impactful research
2. A comprehensive analysis of code and data availability in biomedical research
3. Analytical code sharing practices in biomedical research
4. Code sharing and reproducibility in survey-based social research: evidence from a large-scale audit
5. Code and Data Sharing Practices in the Radiology Artificial Intelligence Literature: A Meta-Research Study.
6. Toward Reproducible Computational Research: An Empirical Analysis of Data and Code Policy Adoption by Journals
7. Formalistic data and code availability policy in high-profile medical journals and pervasive policy-practice gaps in published articles: A meta-research study
8. An assessment of data and code sharing in research funded by the Nathan Shock Centers, 2017-2022: a meta-research study
9. Why sharing data and code during peer review can enhance behavioral ecology research
10. Sharing practices of software artefacts and source code for reproducible research
11. Warp analysis research pipelines: cloud-optimized workflows for biological data processing and reproducible analysis
12. Improving reproducibility of data analysis and code in medical research: 5 recommendations to get started
13. Reproducible and reusable research: are journal data sharing policies meeting the mark?
14. Towards an international electronic repository and virtual laboratory of open data and open-source software for telehealth research: comparison of international, Australian and Finnish privacy policies.
15. A Low-Code Data Anonymization Platform for Achieving Data Privacy for Research Data
16. Creating and sharing reproducible research code the workflowr way