Git & GitHub for Research

Version control tracks every change you make to a project — who changed what, when, and why — so nothing is ever lost and you can roll back to any earlier state. In this course, your version history is also how you submit your work. This section sets up Git and GitHub and walks through the core workflow.

Git and GitHub

Git is version control software that runs on your machine (or the Yens). It tracks every change you make to a project — who, what, and when — and lets you roll back to any previous state.

GitHub is a website that hosts git repositories in the cloud. It’s where you share, back up, and submit your work.

Type your GitHub username and every command on these pages fills itself in, so you can copy and paste them without editing. It stays in this browser.

Git saves snapshots on your machine; GitHub stores them in the cloud. You push commits up to your fork and pull updates back down. 💻 Your machine · the Yens git add · git commit saves snapshots locally GitHub · the cloud YOUR_USERNAME/yens-onboarding-2026 your fork — backup & submission push pull

Git saves your work as commits — snapshots of your whole project at a moment in time, each with a short message describing what changed. Your history is a chain of these snapshots, and you can return to any earlier one at any time.

A commit is a snapshot of your project. Your history is a chain of commits, oldest on the left, newest on the right. main time → init project add cleaning scripts add plotting scripts generate paper.pdf latest

Each dot is one commit — a saved snapshot. The chain runs oldest (left) to newest (right).

A branch is a git feature that lets you build a separate line of commits without disturbing your main work. You branch off, commit there, and merge back when the work is ready — so a risky experiment never touches your working version.

A branch is a separate line of commits. You branch off main, make commits on the branch, then merge them back — main stays intact until you do. main branch off merge back experiment

You branch off main, make commits on experiment, then merge them back. main stays intact until you do.

The workflow for this course:

Three steps. Step 1, fork the shared course repo to your own GitHub account. Step 2, clone your fork down to the Yens, where you work. Step 3, push your finished work back up to your fork. ON GITHUB · THE CLOUD Course repo gsbdarc/yens-onboarding-2026 Your fork YOUR_USERNAME/yens-onboarding-2026 ① fork Your working copy edit → git add → git commit 💻 ON THE YENS · WHERE YOU WORK ② clone ③ push

Three numbered steps: ① fork — make your own copy of the course repo on GitHub · ② clone — download that copy to the Yens, where you actually work · ③ push — send your finished work back up to your fork.

Each day’s challenge is submitted with a git push to your fork as proof of work. No push, no submission.

You’ve now met the two core git ideas — commits and branches. Two more features come from GitHub (the hosting side) and show up later in the course:

  • Issue — a written note attached to the repo: a task to do, a bug you hit, a question to revisit. Issues are timestamped and searchable, so they can serve as a running log if you choose to use them that way.
  • Pull request (PR) — a proposal to merge one branch into another. It shows exactly what changed and lets you (or a collaborator) review the changes before they become part of the main version.

Version control isn’t just bookkeeping — it offers a few concrete advantages for research:

Why version control helps research:

  • A readable history of what changed and why. Every commit carries a short message. Instead of guessing what a file used to hold, you scroll its history and read “add cleaning scripts: drop 3 duplicate rows” right next to the exact lines that changed.
  • No more filename soup. You don’t need analysis_final_v2_USETHIS_edited.R to keep track of versions. There’s one analysis.R, and its history holds every past version with an explanation of each change. The filename says what the file is; the history says how it got there.
  • Experiment safely on a branch. Try a risky reanalysis without touching your working results. If it doesn’t pan out, the branch is a record of what you tried rather than a mess to clean up.
  • Project management, even if you barely write code. GitHub’s issues and pull requests aren’t only for software teams — you can use issues to track to-dos, data questions, or bugs, and pull requests to review a change before it’s merged into your main version.
  • Backed up and shareable. Every version is recoverable, and pushing to GitHub backs your work up and lets a collaborator — or your future self — pick it up.

Caveats:

  • Git has a steep learning curve. It’s genuinely confusing for newcomers — expect to lean on notes, cheatsheets, and AI tools at first.
  • GitHub is a commercial product. It’s owned by Microsoft, not a community-run open project. Convenient and widely used, but not neutral infrastructure.
  • Neither is built for data. Git tracks line-by-line changes in text and code, so large or binary files leave the repository slow and bloated — and GitHub enforces file-size limits on top of that. Keep data on the cluster (/yen/projects, /scratch) or in a data repository, not in your repo.

Exercise — Fork, Clone and Push

Set up your copy of the course repo and make your first commit now.

Fork the course repo, clone it to the Yens, authenticate with GitHub, create a branch, commit a file, and push it back to your fork.

Step 1 — Fork the course repo

A fork is your own copy of the course repo, living under your GitHub account. Everything you write over the next two days goes here.

  1. Fork the repo. Go to the course repo on GitHub and click Fork in the top-right corner.
  2. Turn on Issues. Open your fork’s repository settings and, under Features, tick Issues. A fork starts with its issue tracker switched off, and you’ll be logging issues later today.

Step 2 — Clone to the Yens

Cloning downloads your fork onto the machine you’re working on — here, the Yens.

Run this on the Yens, not on your laptop. If you are not still connected from Connecting to the Yens, log back in first — ssh SUNetID@yen.stanford.edu — and confirm with hostname, which should answer something like yen1.

cd ~
git clone https://github.com/YOUR_GITHUB_USERNAME/yens-onboarding-2026.git
cd yens-onboarding-2026

Step 3 — Authenticate with GitHub (one time)

Pushing to your fork has to prove it’s really you. You do that with a Personal Access Token (PAT) — a single-purpose password for the command line — handed to the GitHub CLI (gh) once. After that, git just works. There’s no browser on the Yens, so a token is the simplest way in.

Make one now — it takes two minutes. If you already have a token from previous work, have it to hand instead and skip to gh auth login below.

Do this in your browser, on your laptop:

  1. Open this pre-filled link: Create your token. It’s a classic token with the three scopes you need already checked — repo (push to your fork), workflow (lets you push changes to the GitHub Actions files), and read:org (lets the GitHub CLI sign you in) — and named yen-repo-workflow.
  2. Set the expiration to 1 year — long enough to reuse this token for your research work well beyond this course, with an automatic backstop if it’s ever forgotten or leaked.
  3. Click Generate token, then copy it right away — GitHub shows it only once.

Treat the token like a password: don’t commit it, don’t paste it into a file, don’t share it. If it ever leaks, delete it on GitHub and make a new one.

Give the token to gh — on the Yens:

ml gh-cli           # make gh available on the Yens
gh auth login       # answer: GitHub.com → HTTPS → Authenticate Git → Yes → Paste an authentication token
gh auth setup-git   # let gh remember the token so git never asks you again

Paste the token when gh auth login asks. The gh auth setup-git step then wires gh in as git’s credential helper, so it hands over your token automatically on every git push. In the future, you can use git without needing to authenticate again.

Check it worked — file an issue from the command line.

gh issue create --repo YOUR_GITHUB_USERNAME/yens-onboarding-2026 \
  --title "Checkpoint: gh is authenticated" \
  --body "Filed from the Yens with the GitHub CLI."

It prints a URL — open it and your issue is there on your fork. Two things that go wrong:

  • Issues are disabled for this repository — you skipped Step 1’s second item. Now that gh is authenticated you can fix it without leaving the terminal: gh repo edit YOUR_GITHUB_USERNAME/yens-onboarding-2026 --enable-issues
  • The issue lands on gsbdarc/yens-onboarding-2026 instead of yours — that happens if you drop the --repo flag inside a clone of a fork, because gh offers the parent repo as a target. Keep the flag and it always goes to your own copy.
Setting up gh on your own laptop

You’ll want gh on your laptop too (for the Claude Code work later). Install it, then run the same gh auth login and paste the same token:

  • macOS (Homebrew): brew install gh
  • Windows (in PowerShell — then it’s usable from Git Bash too): winget install --id GitHub.cli
  • Linux / other: see the official instructions

Answer GitHub.com, then HTTPS, then Paste an authentication token:

gh auth login

(On a laptop you can instead choose “Login with a web browser” — but the token works everywhere, so reusing it is one less thing to think about.)

Step 4 — Create a branch

A branch is a safe, separate workspace, so your experiments never disturb the main version of your work.

git checkout -b experiment

Step 5 — Make a change and commit

add chooses which changes go into your next snapshot; commit saves that snapshot with a message describing what changed and why.

echo "Hello from Day 1" > my_first_commit.txt
git add my_first_commit.txt
git commit -m "Add my first commit from Day 1"

Step 6 — Push to your fork

Pushing sends your saved snapshots up to your fork on GitHub — where they’re backed up and, later, where your submitted work can be checked.

git push -u origin experiment

This pushes your branch, not main. Your work is safely on GitHub, but main is untouched — which is exactly the point of branching. To fold the branch into main, open a pull request on your fork and merge it.

Save your checkpoint work with a git push to your fork. Come back to these steps whenever you need to save work.

🔴 Red sticky = I need help

Put one on your laptop lid if you are stuck and an instructor will come to you.

Never Commit a Password

Git’s whole purpose is that nothing is ever lost. That is exactly what makes it the wrong place for a secret: a password, API key, or token that lands in a commit stays in the history, and if that history has been pushed it is on GitHub, in anyone’s fork, and in GitHub’s caches. Deleting the file afterwards does not help — the old commit still holds it.

A committed secret is a leaked secret. Do not try to tidy it up first. Revoke the key — on GitHub, in the AI Playground, wherever it came from — and issue a new one. Only then worry about scrubbing the history, and assume someone already has the old value.

So keep secrets out of the repository from the start. The mechanism is a .gitignore: a list of paths git should refuse to track. Write it before the file exists, because a .gitignore added afterwards does nothing about a secret you already committed.

Exercise — Write a .gitignore

Create a .gitignore in your clone and commit it, so the files that hold secrets can never be staged by accident.

cd ~/yens-onboarding-2026
cat > .gitignore <<'EOF'
# Secrets — never tracked
.env
*.pem
*.key
EOF
git add .gitignore
git commit -m "Ignore secrets"

Then prove it works. Make a file that looks like a leaked credential, and try to commit it the way you would by mistake:

echo "ANTHROPIC_API_KEY=not-a-real-key" > .env
git add .env
git check-ignore -v .env

Git should refuse the git add, and say so:

The following paths are ignored by one of your .gitignore files:
.env
hint: Use -f if you really want to add them.

Then check-ignore names the rule that stopped it — here, line 2 of .gitignore:

.gitignore:2:.env	.env

Both of those are things you can see. That matters more than it sounds: the obvious test is to run git status and check that .env is missing from the list, but an empty list looks the same whether the rule worked, you are in the wrong directory, or you never created the file at all. With a secret, “no warning” is not the same as “safe”. Here, working is loud and broken is silent — check-ignore prints nothing if no rule matches, and git add quietly stages the file.

(If git add succeeds, the file was already tracked before you ignored it. git rm --cached .env fixes that.)

The .env file itself comes back in Managing API Keys, where you put a real Stanford API key in it. Ignoring it now means the key has nowhere dangerous to land later.

Quiz

Answer each one in your head, then open it to check.

1You commit a file. Is it on GitHub?

No. git commit saves a snapshot on the machine you are sitting at — here, the Yens. Nothing reaches GitHub until you git push. That is why the two are separate steps: you can commit on a plane, or make ten commits and push once.

The practical consequence: work that is committed but never pushed exists in exactly one place, and a cluster home directory is not a backup.

2You and a collaborator are working on a project and they find a bug. What should they do?

Open an issue. It puts the problem on the record where both of you can see it, rather than in a message you will lose:

gh issue create --title "Row count drops after the 2019 merge" \
  --body "Expected 4,812 rows, got 4,796. Reproduced on a fresh clone."

Then the fix goes on a branch, and its pull request says Closes #12 — so the problem, the reasoning, and the change that resolved it stay linked. Six months on, that trail is how either of you reconstructs what happened.

3You make improvements to this course and want us to incorporate them. How?

Open a pull request from your fork back to ours. That is what a fork is for: you commit on a branch in your own copy, push it, and then open a PR whose base is gsbdarc/yens-onboarding-2026 and whose head is your branch.

gh pr create --repo gsbdarc/yens-onboarding-2026 \
  --title "Fix the quota figure on Your Data on the Yens" \
  --body "RCpedia now says 80 GB, not 50 GB."

You never need write access to our repo, but you can still propose changes using pull requests from your own fork.

4Should you write your password in analysis.py?

No. A script is code, code gets committed, and a committed secret is a leaked secret. It is also the version that gets shared with a collaborator, pasted into a notebook, and emailed to a co-author.

Put it in a .env file that .gitignore covers, and have the script read it from the environment — the pattern you set up above and use for real in Managing API Keys.

5If analysis.py is in your repo and you delete it, can I still find it on GitHub?

Yes. Deleting a file is just another commit; every earlier commit still contains it, and git log -- analysis.py or the file’s history on GitHub brings it straight back. That is the point of version control — and the reason a secret cannot be un-leaked by deleting the file that held it.

Removing something from the history means rewriting the history, force-pushing it, and still not reaching forks or caches other people already have. Which is why the answer to a committed key is always: revoke it first.

What You Learned

  • Fork, clone, branch, commit, and push with git — version-control every project from day one
  • Commit and push are different steps: a commit is local, and only git push puts it on GitHub
  • Secrets never go in a repository — a .gitignore keeps them out, and a key that was committed has to be revoked, not deleted
  • Issues record problems and pull requests propose changes, including back to a repo you do not own

Next: set up Claude Code and learn what data it can and can’t be given — see Working with Claude Code.

Page last modified: Sep 16, 2026.

Your details

Set these once and the commands on every page fill themselves in. Stored in this browser.

Built with Just the Docs.