# How to Set Up Git for a Lab

The one difference that shapes every other choice in a Git setup for lab use is where the shared copies of your repositories live. A repository is a project folder whose complete edit history is recorded by Git, the version control program underlying nearly all modern software work. You can keep those shared copies on a service someone else runs, on a server your lab runs, or in plain folders on machines you already administer. That single decision drives your costs, your access controls, and most of your maintenance burden.

The rule of thumb: if your lab writes analysis code with no contractual or regulatory limits on where that code can sit, create an organization on a hosted service such as GitHub, adopt a one-page written policy, and move on. Choose a self-hosted server such as GitLab or Gitea only when data agreements, human-subjects protections, or institutional rules make third-party hosting impractical. A bare repository on a machine you already run is a workable stopgap for one or two people, but it offers no web interface, no review tools, and no access control beyond file permissions.

This guide walks through how to set up Git for a lab end to end: the per-computer setup, the options side by side, the criteria that decide real choices, the short policy that keeps any setup usable, and the mistakes that cost labs the most time.

## Why a Lab Needs Git at All

Git records snapshots, called commits, of every file in a repository, together with the author, the timestamp, and a message explaining why the change was made. For scientists, that history pays off in four places.

Reproducibility comes first. Modern analyses are code, whether that code is an R script, a Python pipeline, a Snakemake or Nextflow workflow, or a notebook. When a reviewer or collaborator asks how a figure was produced, the answer should be a specific commit, not a memory of which file was current last March. The expectation of runnable code is now visible in the literature. One bioinformatics evaluation study, for example, released its code and datasets for reproducibility through a university-run Git server.

Parallel work comes second. Branches, which are parallel lines of history inside one repository, let two people modify the same pipeline at once and merge the results deliberately, instead of trading files named analysis_v3_FINAL_jane.R.

Onboarding comes third. A new student runs one clone command, which copies a repository together with its full history, and immediately has every script, every environment file, and the record of past decisions. Environment files, covered in detail below, are the pinned dependency lists that let anyone rebuild the software setup.

Recovery comes fourth. Anything committed is recoverable from any copy of the repository, so a lost laptop or an accidental deletion stops being a catastrophe.

The cost of skipping this discipline is measurable. In one audit of tool-calling benchmarks, repeating the same evaluation setup 23 times produced scores from 57.9 percent to 76.8 percent, a spread large enough to change the conclusions. Even fully scripted work drifts when conditions go unrecorded. A lab that logs the exact commit, environment, and parameters behind every result has bought the cheapest insurance available.

## Step One: Set Up Git on Every Computer

Before any server decision, each computer that will touch a repository needs Git installed and a working identity. This takes about ten minutes per machine.

### Install Git

On Windows, download Git for Windows from git-scm.com and accept the defaults, which include a Git Bash terminal and a credential helper that stores HTTPS passwords in the system keychain. On macOS, install Homebrew and run brew install git, or use the version bundled with Apple's developer tools. On Linux, use the system package manager:

```
sudo apt install git      # Debian, Ubuntu
sudo dnf install git      # Fedora, RHEL
```

Confirm the installation:

```
git --version
```

### Set Your Identity and Defaults

Every commit is stamped with a name and an email, so set them once, globally:

```
git config --global user.name "Rosa Alvarez"
git config --global user.email "ralvarez@university.edu"
git config --global init.defaultBranch main
```

Use the email address tied to the lab's hosting accounts so commits link to the right profiles. Agree as a lab on one email form, usually the university address, so authorship stays consistent across projects. The last line makes main the default branch name for new repositories, which matches what every hosting service expects. A fourth optional setting chooses the editor used for commit messages:

```
git config --global core.editor "nano"
```

### Add an SSH Key

SSH, the standard encrypted remote-access protocol, authenticates you to a server with a cryptographic key pair instead of a password. Generate a key and print the public half:

```
ssh-keygen -t ed25519 -C "ralvarez@university.edu"
cat ~/.ssh/id_ed25519.pub
```

Paste the public key into your account settings on the hosting service, or into the authorized_keys file on a lab server. Test the connection with ssh -T git@github.com or the equivalent for your server. The private key never leaves the machine and must never be committed anywhere.

### The Commands That Do Most of the Work

Git for scientists is less about memorizing commands and more about agreeing on where code lives and how changes get in. Six commands cover nearly all daily use:

```
git status                    # what changed, what is staged
git add scripts/qc.py         # stage a file for the next commit
git commit -m "Add adapter trimming QC report"
git pull                      # fetch and merge changes from the shared copy
git push                      # send your commits to the shared copy
git switch -c qc-thresholds   # create and move to a new branch
```

Add git clone to start from an existing repository, git switch to move between branches, and git merge to combine a finished branch back into main. Members who prefer clicking over typing can use a desktop application such as GitHub Desktop or the Git panel in VS Code, which wrap the same operations.

## Git Setup Options for Labs

The realistic git setup options for labs differ mainly in who runs the server holding the shared copies. The table below is the core of this article, and the sections after it examine each row on its own terms.

| Option | Shared copies live on | Who runs it | Access control | Review and automation | Best fit | Main drawback |
|--|--|--|--|--|--|--|
| Hosted service (GitHub, GitLab.com, Bitbucket) | Vendor cloud | The vendor, you manage members | Teams, per-repo roles, enforced two-factor | Built in, mature | Most labs, external collaboration, publishing code | Code sits on third-party servers |
| Self-hosted GitLab Community Edition | Your own server | Your lab or central IT | Full control, university sign-on possible | Built in, mature | Regulated projects, institutional control, heavy automation | Real maintenance load, needs a substantial server |
| Self-hosted Gitea or Forgejo | Your own server | Your lab or central IT | Full control | Present but lighter | Small labs that want self-hosting without the weight | Smaller ecosystem, fewer built-in features |
| Bare repositories on existing storage | A lab server or cluster | Whoever owns that machine | Unix file permissions only | None | A stopgap for one or two people, code only | No web interface, no review, manual everything |
| Hybrid | Hosted service for code, institutional storage for data | Split between vendor and institution | Split | Built in for the code half | Labs with data restrictions | Two systems to document and keep in sync |

CI stands for continuous integration, meaning checks that run automatically on every push. Every row can work. The next section lists each option's pros and cons, and the section after that compares the options on the criteria that decide real choices.

## Pros and Cons of Each Option

### Hosted Services: GitHub, GitLab.com, and Bitbucket

A hosted service stores your repositories on the vendor's servers and adds a web interface, access control, code review, and automation. GitHub for researchers usually starts with an organization, a shared account that owns repositories independently of any person, rather than with a personal account.

A sensible setup sequence:

1. One administrator creates the organization under a role address such as git@lab.university.edu, not a personal email.
2. Create teams that mirror the lab: admins for the principal investigator and lab manager, members for staff and students, and outside collaborators for external partners, with expiring access where the platform supports it.
3. Require two-factor authentication for every member at the organization level.
4. Create a lab-handbook repository holding the written policy, templates, and the onboarding checklist.
5. Start each project from a template repository that already contains a README, a LICENSE, a .gitignore file that lists patterns Git should skip, and an environment file.
6. Protect the main branch so changes arrive only through pull requests, meaning proposed changes that teammates review before merging. GitLab calls these merge requests.
7. Set each repository private by default and make it public at publication time if desired.

Strengths: no servers to maintain, the strongest review and automation tooling, a large pool of collaborators and incoming students who already have accounts, and straightforward publishing, since a tagged release can be deposited with an archive service to obtain a citable identifier.

Trade-offs: your code sits on someone else's servers, which is fine for most code and unacceptable under some data agreements, free tiers carry limits that larger labs eventually notice, and accounts churn as students leave unless repositories live under the organization. Choose a license early, following your institution's guidance, because code without a license is code nobody else may legally reuse.

### Self-Hosted GitLab or Gitea on a Lab Server

Self-hosting means running the sharing layer on hardware you control. GitLab Community Edition is a complete platform with repositories, merge requests, continuous integration, and a container registry, and it can authenticate against university sign-on systems. It needs a substantial server, so plan for a machine with several gigabytes of RAM and follow the vendor's current installation guide. Gitea and its community fork Forgejo are deliberately light, run as a single binary with a small database, and cover repositories, pull requests, and optional runners for automation.

Whichever you choose, the administrative duties are the same list: operating system and application updates, HTTPS certificates, backups, offsite copies of those backups, and disk monitoring. GitLab ships a backup command, gitlab-backup create, and Gitea offers gitea dump. A backup that has never been test-restored is a hope, not a backup, so schedule a restore drill at least once a year. Place the server behind the university network or a VPN where possible, and watch disk usage, because a full disk on a Git server blocks every push.

Strengths: full institutional control, data never leaves your machine room, no per-user fees, and integration with university identity systems.

Trade-offs: someone must own updates, patches, and restores, downtime is yours to fix, and a neglected self-hosted server is worse than any hosted service. Do not self-host without naming the person who owns it.

### Bare Repositories on Servers You Already Run

A bare repository contains only the history database, with no checked-out files, and exists purely as a hub that others push to and pull from. It is the original way to share Git repositories and still works anywhere SSH works:

```
git init --bare --shared=group /srv/git/rnaseq-pipeline.git
```

Give the directory a Unix group containing your lab members, then point remotes at it:

```
git remote add origin alvarez@cluster:/srv/git/rnaseq-pipeline.git
git push -u origin main
```

Server-side hooks, which are small scripts that run on push, can add minimal checks such as rejecting commits that add files above a size limit, but each hook is one more script someone must maintain.

Strengths: uses hardware you already have, works on isolated networks, and requires no new systems.

Trade-offs: no web interface, no review workflow, no notifications, permissions managed as Unix groups, and a single disk holding the only shared copy unless you add backups. Acceptable for a two-person project or as a stepping stone, not as a lab-wide solution.

### The Hybrid Pattern

Most labs with any data restrictions end up hybrid: code, documentation, and environment files on a hosted service or an institutional Git server, and data on approved institutional storage, linked by checksums recorded in the repository. The pattern costs little and satisfies most agreements, because the code is what needs review and sharing, while the data needs custody, not a web interface.

## Choosing the Best Git Setup for Your Lab

The best git setup for lab work matches your constraints rather than any platform's feature list. Five criteria decide it.

Data rules come first. If human-subjects protections, clinical data rules, or an industry agreement restrict where material can be stored, ask your institution's research IT or compliance office before the first commit, not after. Even strict agreements usually permit code on a hosted service while data stays in approved storage, which is exactly the hybrid pattern.

Administration capacity comes second. Name the person who owns the server, its patches, and its restores. If no one owns it, choose hosted.

Collaboration surface comes third. External collaborators, community contributions, and published code all favor hosted services, where an email invitation is the entire onboarding process.

File sizes come fourth. Git is built for text and struggles with large binary files, which bloat history permanently. Keep data out of Git, or use Git LFS, the large-file extension that stores big files outside normal history while keeping lightweight pointers in the repository, only sparingly. This criterion shapes policy more than platform choice, and the policy section below handles it.

Longevity comes fifth. Labs dissolve, principal investigators move, and students graduate. Ask where the repositories will be in five years, after two students and one postdoc have left. Prefer arrangements that survive those events: organization ownership rather than personal accounts, periodic archive exports, and institutional affiliation where available.

Score your options against these five and one choice usually becomes obvious. When two tie, pick the one with less to maintain.

## The Policy That Makes Any Setup Work

Tools do not create order, written agreements do. A one-page policy, stored in a lab-handbook repository everyone can read, prevents most of the failures listed later in this article. The stakes are documented: a review of prediction models for miRNA-disease associations found that data leakage and inconsistent evaluation inflate reported performance and block fair comparison between methods [1]. A written policy is the lab-scale version of the fix, consistent, recorded, reviewable practice.

### What Belongs in a Repository

Commit code, small configuration files, documentation, container definitions, and environment files. An environment file is a pinned list of software dependencies that lets anyone rebuild the computational environment. Standard examples are environment.yml for conda, requirements.txt for pip, and renv.lock for R. A typical analysis repository contains:

- README.md describing what the project is and how to run it
- LICENSE naming how others may use the code
- .gitignore listing files Git should skip
- environment.yml or the equivalent for your language
- scripts/ or src/ holding the code
- notebooks/ holding cleaned notebooks without bulky outputs
- config/ holding small parameter files
- results/ holding small tables and figures worth tracking

Name repositories after projects, not people: rnaseq-pipeline rather than janes-stuff. The shared copy is the single source of truth, so if a result matters, its code is pushed.

### What Never Belongs in a Repository

![Four cards listing raw data, credentials, large files, and personal accounts as things to keep out of Git.](/article-images/illustrations/git-setup-for-lab-never-commit.webp)

Raw sequencing data, microscopy stacks, video, patient identifiers, and credentials do not belong in Git. Large files inflate history permanently, because every clone carries every version of every file. Credentials, meaning API keys, tokens, and passwords, are a special case: if one is ever committed, rotate it immediately and treat it as compromised, because deleting a file does not remove it from history.

For data, record checksums instead. A checksum is a short fingerprint of a file's contents, and matching checksums prove two copies of a file are identical:

```
sha256sum data/*.fastq.gz > data/checksums.sha256
```

Commit the checksum file. Anyone can then verify they hold exactly the data the analysis used, while the data itself stays in institutional storage.

### Branch and Review Rules

- main is protected and always in a working state.
- Work happens on short-lived branches with descriptive names such as qc-thresholds.
- Changes to shared pipelines land through pull requests with at least one review.
- Commit messages are one line, imperative, and specific: "Add duplicate removal before counting," not "fix."
- Code used in a manuscript is tagged, for example with git tag -a manuscript-v1, so the exact version stays citable.

### Onboarding and Offboarding

Onboarding checklist: account created and added to the organization, SSH key configured, identity set, handbook cloned, one practice commit merged. Offboarding: remove access within days of a departure, transfer ownership of any personal repositories holding lab code, and archive the departing member's working copies if they hold unmerged work. Review the member list every semester. This is also where longevity lives, because an organization with a reviewed member list survives a lab's full life cycle.

## From Zero to First Push

![Flow of clone, branch, stage and commit, push, then pull request and merge for a small RNA-seq pipeline.](/article-images/illustrations/git-setup-for-lab-first-push.webp)

Here is the whole loop for a [small RNA-seq](/knowledge/molecular-biology/small-rna-seq) pipeline, once Git is installed and an SSH key is registered with a hosted service. To work on an existing repository a teammate created:

```
git clone git@github.com:plant-lab/rnaseq-pipeline.git
cd rnaseq-pipeline
git switch -c add-qc-step
# edit scripts, then
git add scripts/qc_report.py
git commit -m "Add adapter trimming QC report"
git push -u origin add-qc-step
```

Open the web interface, start a pull request from add-qc-step into main, request a review, and merge after approval. To create the first repository from scratch:

```
mkdir rnaseq-pipeline
cd rnaseq-pipeline
git init
# add README.md, LICENSE, .gitignore, environment.yml
git add .
git commit -m "Initial pipeline skeleton"
git remote add origin git@github.com:plant-lab/rnaseq-pipeline.git
git push -u origin main
```

What happened, in order: clone copied the repository with its full history, switch -c created an isolated branch, add staged the changed file, commit recorded a snapshot with a message, push uploaded the branch, the pull request requested review, and the merge incorporated the change into main. That loop, repeated, is the entire daily workflow of a functioning lab.

## Three Worked Scenarios

### A Computational Biology Lab of Eight

The lab mixes R, Python, and Snakemake, and handles no restricted data. The choice is a GitHub organization with three teams, protected main branches, continuous integration that runs syntax checks and unit tests on every push, environment files committed in every repository, and data on university storage referenced by checksums. New projects start from a template repository, so the first commit of any project already has a README, a license, and a dependency list. Publication means tagging a release and depositing it for an identifier. Nothing here requires a server the lab owns.

### A Lab Working With Human Genomic Data

A data use agreement restricts identifiable genomic data to an institution-approved enclave. The lab runs the hybrid pattern. Code, documentation, and environment files sit in a private hosted organization, or on an institutional Git server if the agreement extends to code. Data lives only inside the enclave, the pipeline runs there, and exported result tables are recorded in the repository with checksums. The deciding conversation happened with the compliance office before setup, and the written policy states plainly that no data file is ever committed.

### A Wet Lab Running Analyses on an HPC Cluster

A small lab keeps R scripts and submits jobs to a university high-performance computing (HPC) cluster scheduled by SLURM. Their gait analysis work uses DeepLabCut-based tooling, and even where such tools ship streamlined installers, as Visual Deep Lab Cut does with its single Windows executable [2], the surrounding environment is finicky enough that the lab commits its exact environment file and a setup script to the repository. Repositories are cloned to the cluster over SSH, working copies live in project space, outputs go to scratch, and a bare repository on cluster storage serves as an internal hub, mirrored to a hosted service for sharing and publication. Outputs are never committed.

## Connecting Git to the Rest of the Lab

**Cluster work.** Clone over SSH, pull before starting runs, and keep repositories in home or project space rather than scratch, since scratch is often wiped. Have job scripts print the current commit with git rev-parse HEAD so every log file records the code version that produced it.

**Continuous integration.** On every push, run the checks that catch breakage early: syntax checks, unit tests against a small test dataset, and notebook execution. Both major hosted platforms and self-hosted GitLab provide this natively, and a failing check can block a merge before the breakage reaches main.

**Environments and containers.** Commit environment.yml, requirements.txt, renv.lock, and container definitions such as a Dockerfile or an Apptainer definition file, so the exact computational environment travels with the code. This is the difference between code that reruns and code that merely exists.

**Data provenance.** Keep data in approved storage, record checksums in the repository, and consider established tools such as DVC, which version large data alongside a repository without committing file contents into Git history.

**Manuscripts and publishing.** Keep manuscript source under version control alongside analysis code, tag the release used for submission, and deposit that release for a citable identifier. Reproducible setups shipped with papers, sometimes as cloud notebook environments with public code, are now routine in the computational literature.

## Common Mistakes and Limitations

**Committing large data files.** This is the most expensive mistake, because history grows permanently and removing a file requires rewriting history that every member must then re-download. Prevent it with a .gitignore from the first commit and checksums for data.

**Committing credentials.** Rotate any leaked key immediately, use the history-rewriting tools if you must, and assume the credential was seen.

**Running without a written policy.** Every member invents a workflow, main breaks, reviews stop happening, and nobody can say which version produced a figure.

**Treating Git as an occasional backup.** Weeks-long gaps between pushes produce giant merge conflicts and messages like "updates." Small, frequent commits with specific messages are the habit that makes everything else work.

**Personal accounts as the only home.** Code disappears when a student graduates. Organizations exist to prevent exactly this.

**Skipping access reviews.** Departed members keep write access for years. Put the member-list review on the semester calendar.

**Assuming the repository is an archive.** Git stores text efficiently and stores data poorly. Institutional repositories and approved storage handle archives.

**Over-engineering the setup.** Self-hosting with no named administrator produces a worse outcome than the plainest hosted service. Match the setup to the maintenance you can actually staff.

**Skipping environment files.** Code without pinned dependencies cannot be rerun, which defeats the main reason a lab adopts Git.

**Force-pushing shared branches.** Rewriting history that others have already built on creates days of cleanup. Protect shared branches against it.

One limitation deserves its own paragraph. Git solves code history, not [data management](/blog/guides/data-management-basics-principles-processes-and-best-practices), instrument records, or laboratory notebooks unless you deliberately place them under version control, and labs handling regulated data need decisions from their institution's compliance and IT offices before adopting any arrangement described here. Revisit the whole setup yearly as the lab's people and projects change.

## Frequently Asked Questions

### Is Git the same as GitHub?

No. Git is the version control program that records history on your own computer, and GitHub is a hosting service that stores shared copies of Git repositories and adds review, access control, and automation on top. A lab can use Git without GitHub, but not GitHub without Git.

### Should our lab use GitHub or GitLab?

Either works well. Choose GitHub if you want the largest pool of external collaborators and ready-made automation, and GitLab if you want one platform that could also be self-hosted later with the same interface. The written policy matters more than the platform choice.

### Can we store patient or human-subject data in a private repository?

No. Keep regulated or identifiable data in approved institutional storage, keep only code, small configurations, and checksums in Git, and confirm the boundary with your compliance office before the first commit.

### How do we handle large files such as sequencing data or microscopy images?

Keep them out of Git. Store them on institutional or dedicated storage, record their checksums in the repository, and reserve Git LFS, the large-file extension, for the occasional files that must travel with the code.

### Do students and staff need to learn Git commands?

They need only a small core set, and desktop applications can cover most of it. The administrator of the lab setup needs more depth than the average member, but daily work is six or seven commands.

### What happens to our repositories when the lab closes or the principal investigator moves?

Plan for it in advance. Keep repositories under a lab or department organization rather than a personal account, export periodic archive copies, and record who takes ownership when members leave.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Is Git the same as GitHub?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "No. Git is the version control program that records history on your own computer, and GitHub is a hosting service that stores shared copies of Git repositories and adds review, access control, and automation on top. A lab can use Git without GitHub, but not GitHub without Git."
      }
    },
    {
      "@type": "Question",
      "name": "Should our lab use GitHub or GitLab?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Either works well. Choose GitHub if you want the largest pool of external collaborators and ready-made automation, and GitLab if you want one platform that could also be self-hosted later with the same interface. The written policy matters more than the platform choice."
      }
    },
    {
      "@type": "Question",
      "name": "Can we store patient or human-subject data in a private repository?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "No. Keep regulated or identifiable data in approved institutional storage, keep only code, small configurations, and checksums in Git, and confirm the boundary with your compliance office before the first commit."
      }
    },
    {
      "@type": "Question",
      "name": "How do we handle large files such as sequencing data or microscopy images?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Keep them out of Git. Store them on institutional or dedicated storage, record their checksums in the repository, and reserve Git LFS, the large-file extension, for the occasional files that must travel with the code."
      }
    },
    {
      "@type": "Question",
      "name": "Do students and staff need to learn Git commands?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "They need only a small core set, and desktop applications can cover most of it. The administrator of the lab setup needs more depth than the average member, but daily work is six or seven commands."
      }
    },
    {
      "@type": "Question",
      "name": "What happens to our repositories when the lab closes or the principal investigator moves?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Plan for it in advance. Keep repositories under a lab or department organization rather than a personal account, export periodic archive copies, and record who takes ownership when members leave."
      }
    }
  ]
}
</script>

## Further Reading

- [RepliCueAuth: Validating the Use of a Lab-Based Virtual Reality Setup for Evaluating Authentication Systems](https://doi.org/10.1145/3411764.3445478)
- [Grey-Box Modeling and Decoupling Control of a Lab Setup of the Quadruple-Tank System](https://doi.org/10.3390/act13030087)

## Sources

1. [Towards a consistent evaluation of miRNA-disease association prediction models](https://doi.org/10.1109/BIBM49941.2020.9313142)
2. [Visual Deep Lab Cut: A user-friendly approach to gait analysis.](https://pubmed.ncbi.nlm.nih.gov/32428621/)