Welcome to the group. One of the first things you will be asked to do is get comfortable with Git and GitHub. If you have never used either before, this post is for you. If you have used them before but only loosely, it is still worth a read — especially the paper discussed at the end.
What Is Git?
Git is a version control system. It tracks changes to files over time so that you always know what changed, when it changed, and who changed it. Think of it as an unlimited undo history for your entire project, combined with the ability to work on multiple versions of something simultaneously.
Here is the key idea: without Git, you probably manage versions of files like this:
analysis_final.py
analysis_final_v2.py
analysis_final_v2_REVISED.py
analysis_final_v2_REVISED_USE_THIS_ONE.py
With Git, there is only one file. Git keeps the full history internally, and you can travel back to any point in time with a single command.
Git was created by Linus Torvalds in 2005 (the same person who created the Linux kernel) and is now the most widely used version control system in the world. It runs entirely on your local machine — no internet connection required.
Some things Git lets you do:
- Commit — save a snapshot of your work at a meaningful point
- Branch — create a parallel version to try something without touching the main code
- Merge — bring changes from one branch back into another
- Diff — see exactly what changed between any two versions
- Log — browse the full history of a project
What Is GitHub? And How Is It Different from Git?
GitHub is not Git. This is one of the most common points of confusion for new users.
Git is the tool — software that runs on your computer and tracks changes locally.
GitHub is a hosting service — a website where you can store your Git repositories online, share them with collaborators, and use additional features like issue tracking, pull requests, and project boards.
The relationship is like this: Git is the engine, GitHub is the garage where you park and share the car.
You can use Git without GitHub entirely. Many people do. But hosting your repository on GitHub makes collaboration much easier, because everyone on the team can push and pull changes to a shared remote copy of the project.
GitHub Is Not the Only Option
GitHub is the most popular Git hosting service, but it is far from the only one. Other widely used platforms include:
- GitLab — similar to GitHub; popular in academic and enterprise settings; can be self-hosted
- Bitbucket — popular in teams that use Atlassian tools (Jira, Confluence)
- Codeberg — a nonprofit, open-source alternative
- Gitea — lightweight and self-hostable
They all work with standard Git. If you learn Git on GitHub, you can move to any of the others without relearning the fundamentals.
In our group, we use GitHub. That is where our repositories live, where issues are tracked, and where code review happens. When this post refers to GitHub, that is what we mean.
Git and GitHub in the Lab: A Recent Paper
A 2025 paper in PLOS Biology makes the case that GitHub is not just for software teams — it belongs in the research lab too.
Chen KY, Toro-Moreno M, Subramaniam AR. GitHub enables collaborative and reproducible laboratory research. PLOS Biology. 2025;23(2):e3003029. DOI: 10.1371/journal.pbio.3003029
The authors — researchers at the Fred Hutchinson Cancer Center — describe how they adapted GitHub’s standard software development workflows for wet-lab research. Their argument is simple: the same problems that version control solves in software (losing track of changes, difficulty collaborating, poor reproducibility) exist in laboratory science, and GitHub can solve them there too.
Their Three-Part Framework
1. Issues for Experiment Organization
GitHub Issues are typically used to track bugs and feature requests in software. The authors repurpose them to outline experimental designs, document troubleshooting, and summarize results — all in one place that the entire team can see and comment on. Every experiment becomes a thread with a full discussion history.
2. Version Control for Documentation
Lab notebooks, analysis scripts, and data summaries are stored in Git repositories in plain text formats. Every change is committed with a message explaining what changed and why. This creates an auditable trail of the entire project’s evolution — something a shared Google Doc or a folder full of PDFs cannot provide.
3. Containerization for Reproducibility
Software containers (such as Docker or Singularity/Apptainer) package the exact computing environment alongside the code. This means that an analysis run today can be reproduced exactly in two years, on a different machine, by a different person.
Key Takeaways
The authors conclude that this approach is versatile, scalable, and free to start. Their practical advice:
- Start with Issues only. You do not need to use every feature at once. Get comfortable with issue tracking before adding version control for everything.
- Use templates. Standardized repository structures reduce the overhead of starting a new project.
- Know the limits. GitHub is not designed for very large datasets or data subject to HIPAA or other compliance requirements. For those cases, other solutions are needed.
The paper also notes an important human benefit: when a lab member leaves, their work does not leave with them. A well-maintained GitHub repository is a form of institutional memory.
What This Means for You
As an intern in this group, you will be expected to use Git and GitHub from day one. That means:
- Keeping your code and analysis scripts in a repository
- Writing commit messages that explain what you did and why
- Using Issues to document experiments, questions, and results
- Submitting changes through pull requests so they can be reviewed
If you are new to Git, the best way to learn is to use it on a real project. Start small — commit often, and do not worry about making it perfect. The history is there to catch you if something goes wrong.
If you have questions, open an Issue. That is what they are for.