← Lab 7

A lab notebook for code

You already keep a record of every experiment you run. Git is that record for the analysis: what you changed, when, why — and a way back to any of it.

Four afternoons you will lose without it
  • ▸You changed four cells, nothing works, and you cannot remember what you changed
  • ▸Yesterday's version ran. Today's does not. Yesterday's is gone
  • ▸Your laptop is the only copy of three weeks' work
  • ▸Your supervisor asks which version made the figure in the draft
The folder everyone ends up with
the usual approach
analysis.py
analysis_v2.py
analysis_v2_fixed.py
analysis_FINAL.py
analysis_FINAL_really.py

Every one of these is a commit you made by hand, with no date, no message and no way to see what changed between them. Git does the same job properly, and the folder stays clean: one analysis.py, with its whole history behind it.

Start a repo, then ask where you are

Two commands. The first you run once per project; the second you run constantly, and it tells you everything about the state you are in.

In the terminal, inside your project folder
terminal
cd lab07
git init
git status

Git will also ask who you are, once per machine:

terminal
git config --global user.name "Your Name"
git config --global user.email "you@sussex.ac.uk"
What to know
  • ▸git init makes one hidden folder, .git. That folder is the repository
  • ▸Delete .git and you have an ordinary folder again. Nothing else is touched
  • ▸One repo per project. Not one for your whole laptop, and not one per file
  • ▸git status is the command you type most. When lost, type it

The add, commit cycle

This is the whole of git, for now. Edit something, decide it is worth keeping, write down why. Repeat several times an hour.

The cycle
terminal
# ... you edit 01_find_the_suspects.ipynb ...

git status                  # what changed?
git add 01_find_the_suspects.ipynb
git commit -m "add the skin-minus-rest difference"

git status                  # clean again
Why two commands and not one
  • ▸git add does not save anything. It chooses what goes into the next snapshot
  • ▸git commit takes the snapshot, with your message attached
  • ▸git add . stages everything that changed — fine while you are learning
  • ▸A good message says why: “drop the 2018 surveys, dates were wrong”, not “update”

Commit when something works, not when you stop for lunch. Each commit should be one idea, so that going back to it gives you something that runs.

Reading the history

A record you cannot read is not worth keeping. These four commands are how you answer “what did I do, and when did it break?”

Four commands
git log --oneline
every commit, one line each, newest first
git diff
what you have changed but not yet staged
git diff --staged
what is about to go into the next commit
git show 7a3f21c
exactly what that one commit changed
git log --oneline -- notebook.ipynb
the history of a single file
What a log looks like
git log --oneline
9c1d4e2 use blue light, not UV
3b77a10 drop the 2018 surveys
7a3f21c add skin-minus-rest
0e5c8d9 first commit

The short code is the commit's name. You use it to look at a commit, and to go back to one.

The command that earns its keep

Everything so far is bookkeeping. This is the payoff: the afternoon you break something badly and get it back in one command.

Undo today's mess
terminal
# one file, back to the last commit
git restore analysis.py

# everything, back to the last commit
git restore .

# just look at an old version first
git show 7a3f21c:analysis.py

Try it now: break a notebook on purpose, save it, then bring it back.

Read this before you use it
  • ▸git restore throws away your uncommitted changes. That is the point, and there is no undo
  • ▸It can only give you back what you committed. Commits are the save points
  • ▸Nothing committed is ever really lost, even when it looks like it

This is the real argument for committing often. A commit every twenty minutes means you can never lose more than twenty minutes.

What not to commit

A repository is for the things you wrote. Not for what your computer generated, and not for the raw data — which matters immediately, because the DepMap files are large.

Make this file before your first commit
.gitignore
.venv/
__pycache__/
.ipynb_checkpoints/
.DS_Store

# data: big, and not ours to redistribute
data/*.csv
!data/depmap_lecture.csv

The last line is an exception: ignore every CSV except the small teaching file, so everyone who clones the repo can still run the notebooks.

Why it matters
  • ▸Data files are big, and GitHub refuses anything over 100 MB
  • ▸A virtual environment is thousands of files you can recreate in one command
  • ▸Committed junk never really goes away — it stays in the history
  • ▸Never commit passwords, API keys, or anything with patient or personal data in it

Link it to GitHub, then push

Everything so far lives on your laptop. One more step puts a copy somewhere that survives a spilled coffee — and gives you something to show.

Once per project
terminal
gh auth login              # once per machine

# make an empty repo on github.com, then:
git remote add origin https://github.com/you/lab07.git
git branch -M main
git push -u origin main
Every time after that
terminal
git add .
git commit -m "what I changed and why"
git push
The bits that confuse everyone
  • ▸origin is just a nickname for the GitHub address. Nothing magic about the word
  • ▸-u links your main to theirs, once. After that git push is enough
  • ▸GitHub will not accept your account password. Use gh auth login
  • ▸Your commits stay local until you push. Pushing is the backup

Make the repo private if you prefer. You can make it public later; going the other way is harder.

Branches: not today

You will hear about branching and merging, and one day you will need them. Working alone on one machine, they solve a problem you do not have yet — so here is what they are for, and where to learn them properly.

What you are missing
  • ▸A branch is a second line of history, so you can try something risky without touching the version that works
  • ▸Merging brings it back. If you both changed the same line, git asks you to choose — that is a conflict, and it is normal
  • ▸This earns its keep when other people are in the repo, or when a change takes days
What actually makes the difference
  • ✓Commit often, with messages you could read back in a month
  • ✓Push at the end of every session
  • ✓git status whenever you are unsure
  • ✓git restore when you break something
DataCamp · Introduction to Git →