Skip to main content

Sharing your code on GitHub

Keeping your R code on GitHub, so supervisors can follow it and you can work with others.
Last updated

November 12, 2026

Draft, November 2026. Comments welcome!

Most of us do our analyses in RStudio, and the scripts usually live in a Dropbox or OneDrive folder. That’s fine for working on your own. It gets harder once someone else wants to follow along: a supervisor who wants to see where you are, a co-author who wants to rerun a model, or two of you working on the same scripts.

GitHub solves this, and it’s a smaller step than it sounds. You keep working in RStudio as before. Now and then you click two buttons, and your latest code is on GitHub, where the people you’ve invited can see it.

Why it helps

  • Your supervisor can follow your work. We can look at your latest scripts at any time, without you having to send files around, and see exactly what changed since last time, line by line. That makes it much quicker to help when you’re stuck.
  • Nothing is lost. Every saved step stays in the history. You can always go back to the version that worked last week, or see when and why a result changed.
  • Working together is easier. Two or more people can work on the same repository, and Git brings the changes together instead of you emailing analysis_v3_final_LN.R back and forth.
  • Your work is ready to share. When the paper comes out, the code that produced it is already in one place, and can be made public with a DOI (see below).

What goes where

Think of it as three kinds of files, in two places.

Code goes on GitHub. R scripts, R Markdown and Quarto files, small helper files, and a short README that says what the project is and how to run it.

Small data can go on GitHub too, as long as the repository is private and no data agreement says otherwise. A few CSV files of a few megabytes are fine. GitHub refuses single files over 100 MB, and things get slow well before that.

Large or sensitive data stay in your synced Dropbox or OneDrive folder (or on our group server). That includes:

  • raw data, and anything over a few tens of MB;
  • data that belong to partners (the Kalahari Research Centre, Wild Nature Institute and others). Check the agreement before any of it goes to GitHub, whose servers are not in Switzerland. When in doubt, keep it out;
  • exact locations of dens, nests, collared animals or threatened species;
  • personal data, such as names of observers or hunters.

Large outputs also go to the synced folder, not to GitHub. Git is made for text files that change line by line. Big or binary files bloat the repository and can’t be compared between versions anyway. So write these to Dropbox or OneDrive:

  • figures (PNG, PDF, TIFF) and rendered reports (HTML, PDF, Word);
  • saved model fits and MCMC samples (.rds, .RData), and simulation output;
  • rasters, shapefiles and downloaded climate or satellite data;
  • photos, camera-trap images, audio and video;
  • manuscript drafts in Word or PDF.

The code that makes these files is on GitHub, so you can always make them again.

Never put a Git repository in a synced folder

This is the one rule that really matters. Don’t keep a repository inside Dropbox, OneDrive, iCloud Drive or any other folder that syncs by itself. Git and the sync service both try to manage the same files. Sooner or later that gives you a broken repository or “conflicted copy” files. GitHub already backs up and syncs your code, so you don’t need Dropbox for that.

Keep your repositories in a plain local folder instead:

  • on a Mac: ~/git/ (for example ~/git/rotifer-analysis). Check that Desktop & Documents syncing in iCloud doesn’t cover it.
  • on Windows: C:\Users\<you>\git\. Not your Documents folder, which OneDrive often syncs on UZH computers.

Your code then lives in ~/git/, and your data and outputs in Dropbox or OneDrive. The next section shows how your scripts find the data.

Point your scripts to the data

Your data folder sits at a different path on every computer: ~/Dropbox/... on one Mac, C:\Users\...\OneDrive - Universität Zürich UZH\... on someone else’s. So don’t type the path into your scripts. Set it once on each computer, and the same script runs for everyone.

Open your personal R settings file:

usethis::edit_r_environ()

and add one line with the path to your project’s folder in Dropbox or OneDrive, then restart R:

ROTIFER_DIR="~/Dropbox/Work/Research/Rotifer"

In your scripts, build every path from it:

project_dir <- Sys.getenv("ROTIFER_DIR")
counts  <- read.csv(file.path(project_dir, "data", "counts.csv"))
ggsave(file.path(project_dir, "output", "growth-rates.pdf"), p)

A collaborator sets the same name to their own path, and nothing else changes. The .Renviron file is personal: never commit it.

Set it up once

This takes about 15 minutes.

  1. Create a GitHub account at github.com. As a student or staff member, also apply for GitHub Education: it’s free, and it gives you GitHub’s AI coding assistant Copilot and the paid features on top.

  2. Install Git. On a Mac, type xcode-select --install in the Terminal. On Windows, install it from git-scm.com with the default settings. Then restart RStudio.

  3. Connect RStudio to GitHub. In the R console, run:

    install.packages(c("usethis", "gitcreds"))
usethis::use_git_config(user.name = "Your Name", user.email = "you@uzh.ch")
usethis::create_github_token()   # opens GitHub; create the token and copy it
gitcreds::gitcreds_set()         # paste the token here

    The token expires after the time you choose. When pushing suddenly stops working, make a new one with the same two lines.

  4. Put your project on GitHub. If your RStudio project currently lives in Dropbox or OneDrive, first copy the scripts (not the data) to a new folder in ~/git/, and open the project from there. Then run:

    usethis::use_git()
usethis::use_github(private = TRUE)

    RStudio restarts and a Git tab appears in the top right. Your code is now on GitHub, in a private repository.

  5. Invite the people who should see it. On GitHub, open the repository, go to Settings › Collaborators › Add people, and add your supervisor (Arpat’s GitHub name is arpatoz) and anyone you work with.

On another computer, or someone else’s code: to get a repository from GitHub onto a new computer, or to try out a colleague’s code, use File › New Project › Version Control › Git and paste the repository’s address.

On the group server: Git is already installed in RStudio Server, so skip step 2. Run step 3 in the server’s R console, then get your projects onto it the same way.

If you get stuck, or want to go further, two good tutorials walk through every step: Version control with Git and GitHub (University of Bergen), with screenshots, branches and how to rescue a broken repository, and Happy Git and GitHub for the useR, the standard guide, especially for troubleshooting.

Keep the clutter out

usethis creates a file called .gitignore, which lists what Git should ignore. Add the files your project writes, so figures and model fits stay out of GitHub, plus the hidden files Macs create and any cache folders:

.Renviron
.DS_Store
*_cache/
*.rds
*.pdf
*.png
output/

Your everyday routine

It’s four steps, all in RStudio’s Git tab:

  1. Pull (blue down arrow) when you start, to bring in anything others have changed.
  2. Work as usual.
  3. Commit when you’ve finished a step that makes sense on its own: tick the changed files, click Commit, and write one line saying what you did (“Add temperature effect to growth model”).
  4. Push (green up arrow) to send it to GitHub.

Commit often, in small steps, and push at least at the end of each day. A history of small, clearly described steps is what makes it easy for you, and for us, to see what happened.

If a push is refused (“updates were rejected”), someone pushed in the meantime: pull, then push again. If Git reports a conflict, the same lines were changed on both sides. RStudio marks them in the file with <<<<<<< and >>>>>>>. Keep the right version, delete the markers, commit and push. Or ask your AI assistant to help resolve it.

Getting feedback

Once your supervisor is a collaborator, you don’t need to send anything: just push, and tell them in a line on Slack what to look at. They can comment on a commit, or open an issue in the repository (“The detection model in 02_fit.R doesn’t include year, no?”). You’ll get an email, and the issue stays open until you close it. It’s a simple to-do list for your analysis.

You can open issues yourself, too: for a question you’d like to discuss in your next meeting, or a reminder of something to fix later.

Working on a repository together

When two or more of you work on the same analysis:

  • Agree who owns the repository, and add the others as collaborators.
  • Pull before you start and push when you finish, every time. Most conflicts come from forgetting one of the two.
  • Try not to edit the same script at the same moment. Splitting the work into several scripts (01_clean.R, 02_fit.R, 03_plot.R) helps.

When several of you change the same code a lot, the next step is branches: each of you works on your own copy of the project, without getting in each other’s way, and you merge the changes together when you’re done. This tutorial on working together with Git shows how, from RStudio.

Some good habits

  • Write a README. At the top of the repository: what the project is, where the data are (the folder name, not the data) and what each column means, which variable in .Renviron it needs, which script does what and in which order to run them, and which R packages it uses. An incomplete README makes shared code almost useless, so take the time. This template is a good start, and the SORTEE guidelines say what reviewers and data editors look for.
  • Never commit passwords or tokens. Database logins, API keys and the like go in .Renviron, never in a script. If one slips into a commit, tell us: deleting the file isn’t enough, because it stays in the history.
  • Note your package versions. For a paper or a thesis, the renv package records which versions you used, so the analysis still runs in a few years.
  • Keep your AI sessions with the project, as the AI guide suggests. AI coding assistants like Claude Code also work directly on your repository. You see every change they make in the Git tab before anything is committed.

When you publish, and when you leave

When your paper is accepted, the code behind it can be made public. Many journals ask for it anyway. Make a public copy of the repository (or make it public, if it holds no data you can’t share), and connect it to Zenodo, which archives a version and gives it a DOI that you cite in the paper. If the journal uses double-blind review, Anonymous GitHub makes an anonymised copy of the repository for the reviewers.

When you leave the group, your repositories stay with you. Before you go, we make a copy of them for the group’s archive, so we can still find and rerun the analyses behind our papers.

GitHub or GitLab?

We use GitHub because it fits our work best: RStudio sets it up in a few lines, most of our collaborators are already there, and Zenodo gives the code behind a paper a DOI with one click. UZH also runs its own GitLab, where your code stays on servers in Switzerland. You can use it when a partner or a data agreement requires Swiss servers, though keeping the data off GitHub, in your synced folder as described above, usually solves that too. Everything in this guide works the same way there, except the GitHub-specific setup steps (the token and use_github()), which you do on the GitLab website instead.

Who to ask

For GitHub and setting up a project, ask in #r_clinic on Slack, where someone has usually had the same problem before. For the group server, ask Tim Vink in #intranet. When in doubt about whether data may go on GitHub, discuss it with your supervisor before you push.