This guide is for researchers at the University of Sheffield who need to set up a GitHub Organisation for their team or project. It covers the essential decisions you’ll need to make, explains who is responsible for what, and walks through key security settings.
If you’re already using Git and GitHub for version control (and if you’re not, there are good reasons to start), you’ve probably been working from your personal account. That works fine for solo projects, but research groups face a specific problem: what happens to the code when people leave?
When a PhD student or postdoc moves on, their personal repositories often become “gradware”—abandoned code that the group can no longer access or maintain. An Organisation solves this by giving the research group itself ownership of the code, separate from any individual’s account.
Organisations also let you:
The University’s GitHub Enterprise Early Access Program provides access to these features. This provides several advantages over a standard free account, including:
To get started, you will need to follow the University’s formal onboarding process. Please refer to the GitHub Enterprise Policy Document; specifically, you will find the required setup form in Section 5 (Requesting an Organisation).
💡 Tip: When naming your Organisation, choose something descriptive and evergreen such as UoS-[Institute] or UoS-[Lab-Name], rather than something tied to a specific year or project. An organisation can contain multiple repositories that span multiple projects.
GitHub Organisations need designated Owners—people who take responsibility for the space. This isn’t just a technical role; it comes with ongoing obligations.
You need at least two owners for continuity. These people will be responsible for:
Choose your owners carefully. They should be people who’ll be around for a while and who understand (or are willing to learn) the security implications of managing shared code. The full list of owner responsibilities is in Section 1.3 of the GitHub Enterprise policy.
To prevent an Organisation from becoming “orphaned” when a researcher moves on, we recommend that the Principal Investigator (PI) or a permanent staff member always holds one of the Owner roles. This ensures the department retains access to the research outputs even after students or post-docs finish their contracts.
Once your Organisation is created, you’ll need to configure some settings. You’ll find these under Settings in your organisation’s GitHub page. The GitHub documentation on security settings covers everything in detail, but here are the key ones to address first.
If you’re working with commercially sensitive code, personal data, or anything requiring particular protection, contact the Research & Innovation IT team to discuss your specific needs.
Where: Settings → Member privileges → Repository creation
What to do: Untick “Public” (leave Private and/or Internal enabled)
Why: This prevents anyone from accidentally making a repository public. Research code often needs to stay private until publication—or permanently. With this setting, making something public requires deliberate action by an owner.
Where: Settings → Member privileges → Outside collaborators
What to do: Untick “Allow repository administrators to invite outside collaborators”
Why: Outside collaborators are people who aren’t organisation members but can access specific repositories. Without this control, any repository admin could invite external people without oversight. Centralising this with owners means you always know who has access and can ensure external users meet any contractual or ethical requirements.
Where: Settings → Code security and analysis
What to do: Enable “Dependabot alerts” and “Secret scanning”
Why: These tools watch for common security problems:
Where: Settings → Actions → General → Policies
What to do: Select “Allow enterprise actions and reusable workflows”
Why: GitHub Actions runs automated tasks on your code (tests, checks, deployments). There’s a marketplace of community-built Actions, but not all are trustworthy. Restricting to enterprise-approved actions reduces the risk of malicious code running in your workflows.
Where: Settings → Personal access tokens → Settings
What to do: Under “Tokens (classic)”, select “Restrict access via personal access tokens (classic)”
Why: Personal Access Tokens let scripts access GitHub on behalf of a user. Classic tokens have broad permissions and are a security risk if leaked. This setting forces users to approve which organisations their tokens can access and encourages use of the newer, more secure fine-grained tokens.
Where: Settings → Authentication security
What to do: Tick “Require two-factor authentication for everyone in your organization”
Why: Your organisation’s security is only as strong as its weakest password. Two-factor authentication means that even if someone’s password is stolen, attackers still can’t access your repositories.
Beyond organisation-wide settings, your most important repositories deserve additional protection.
Where: Repository Settings → Branches → Add branch protection rule
What to do: Target your main branch and enable “Require a pull request before merging” and “Require approvals”. While you’re there, also turn on:
Why: Without branch protection, anyone on the team—including you—can push changes directly to your main branch. Requiring a pull request means every change has to be reviewed before it lands: the code equivalent of asking a colleague to read over your work before you send it.
There is a gap in the default pull request setup that is easy to overlook. Once a PR is approved, any team member can still push new commits to the same branch. The approval stays in place even though the code has changed, so those unreviewed commits can be merged straight through—quietly bypassing the review process.
"Dismiss stale approvals" clears existing sign-offs the moment new commits arrive, forcing another review. "Require approval of the most recent push" goes further: it ensures the reviewer explicitly signed off on exactly what gets merged, not an earlier version of it. Without both settings, the approval requirement is straightforward to circumvent, intentionally or not.
Committing data to repositories. GitHub is for code, not data storage. Large files make repositories sluggish, and committing research data may violate ethics approvals. Use a .gitignore file to exclude data files and folders.
⚠️ Warning: GitHub is not a data repository. Never commit raw research data, sensitive participant information, or large binary datasets to GitHub. Use it for code, scripts, and documentation only.
Hard-coding credentials. It’s tempting to put database passwords or API keys directly in scripts. Don’t. Use environment variables or a .env file (added to your .gitignore) to keep credentials separate from code.
This guide covers the essentials, but GitHub offers more for making research software FAIR (Findable, Accessible, Interoperable, Reusable):
Why use ORDA instead of just leaving code on GitHub? While GitHub is excellent for active development, it does not guarantee long-term preservation. To meet most funder requirements, you should archive “frozen” versions of your code in ORDA.
Unlike GitHub, ORDA provides a persistent Digital Object Identifier (DOI). This ensures that when you cite your code in a paper, the link will never break, and other researchers can access the exact version of the software used to produce your results.
For more information on integrating GitHub with ORDA (which is based on the FigShare platform,) please read How to connect Figshare with your GitHub account on the FigShare documentation.
If you are starting a new research organisation today, follow these six steps:
Contact the Research Software Engineering or Research & Innovation IT team if you need help choosing the right settings, working with sensitive data, or troubleshooting permissions issues.
While the security configurations outlined above provide a robust baseline for most projects, it is important to remember that security is not a one-size-fits-all requirement. Not every option needs to be strictly locked down in all circumstances; rather, managing an organization involves making informed judgments and balancing security trade-offs against the specific collaborative needs of your research. If you are uncertain about which settings are appropriate for your project’s unique requirements, or if you need help navigating these decisions, you can contact us for further guidance
We offer a range of short courses throughout the year that are free for all researchers. Learn beginner to advanced skills in popular programming languages, computing, and statistical packages.
As part of the FAIR² for research software curriculum, the Research Software Engineering team provides a two-tiered version control training program tailored specifically for researchers. The journey begins with the “Git, GitHub and GitKraken - From Zero to Hero” module, which introduces absolute beginners to version control basics and collaborative workflows using graphical tools. For those looking to level up, the “Git With It” session dives deeper into branch management, commit history, and advanced collaboration techniques. Together, these modules empower researchers to move beyond basic file saving, ensuring their code is reproducible, organized, and ready for collaborative open research.
These resources provided by other Universities may be useful as you learn to collaborate on research software using GitHub:
For queries relating to collaborating with the RSE team on projects: rse@sheffield.ac.uk
Information and access to Bede.
Join our mailing list so as to be notified when we advertise talks and workshops by subscribing to this Google Group.
Queries regarding free research computing support/guidance should be raised via our Code clinic or directed to the University IT helpdesk.
List of archived pages: Archive.