Session 04¶

Topic 1: Interfaces¶

Today¶

Git version control¶

workday without and with Git
introducing Git
Git hands-on

Your workday¶

Version 1: without version control¶

8:30: Starting the day¶

open a folder full of files:

analysis_final.ipynb
analysis_final_v2.ipynb
analysis_final_really_final.ipynb

Question: 🤔
Which one produced last week’s results?

→ Without version control, there is no reliable record to find out.

9:45: New features are risky¶

you’re afraid to modify working code
you copy some files to try out a new idea
a new idea has some underlying fear

Result: 😵‍💫

code duplication
diverging logic
missed opportunities to explore

→ Without version control, experimentation becomes unsafe.

11:30: Debugging the past¶

Issue: Your client complains about your code’s performance; it is slower than last month.

you kept no history of changes
no way to see differences (old vs. new)
you have to rely on your memory and guesswork

Your productivity suffers: 🐌

you spent your time on: “What did I change?”
… but not on: “How do I fix this?”

→ Without version control, you debug history instead of code.

14:00: Collaboration breakdown¶

Your teammate helped to find the bug:

his email attachment: analysis_NEW_fixed.py
you have to manually merge that file with your code
you accidentally overwrite some correct code

Your code becomes unsafe: ⚠️

new bugs are introduced
trust to teammates erode

→ Without version control, collaboration does not scale.

16:00: Reproducibility crisis¶

Your manager gets involved:

“Can we reproduce last month’s results?”

Your answer: 😨

“I could not find the old version; fixed one bug but made to another.”

→ Without version control, reproducibility is fragile, because results are disconnected from code.

End of the day¶

What the day felt like 🫨

stressful
uncertain
hard to move forward

What we need is 🧭

Version control removes chaos so data science can scale.

Version 2: with version control - Git¶

8:30: Starting the day¶

look at changes not files
clear entry points, no guessing 🧐
start the day with (we will learn these):

git status
git pull
git log

→ With Git, there are reliable records tracking changes in code.

9:45: New features are safe¶

new idea, no fear
create a branch for the idea:

git switch -c new-feature-experiment

your main code remains untouched

Result: 💡

no file copying
no risk of breaking working code

→ With Git, experimentation is cheap and safe.

11:30: Understanding changes¶

Issue: A client complains about your code’s performance; it is slower than last month.

Quick insight: 🦉

you check the history of changes:

git log
git diff

see exactly what changed
see exactly when and by whom

→ With Git, you debug the change, not your memory.

14:00: Collaboration that scales¶

Your teammate contributes improvements:

changes arrive via Git (not email)
you see every line that the teammate changed
review and merge cleanly with Git

Code stability and safety: 🔧

no unsafe overwrites
no guesswork
shared ownership of the code

→ With Git, collaboration is structured and reliable.

16:00: Reproducibility by default¶

Your manager gets involved:

“Can we reproduce last month’s results?”

Your answer: 🤓

“Yes, with this commit.”

→ With Git, reproducibility is built in, because Git lets you link an exact code version with your results.

End of the day¶

What the day felt like ⛵️

calm
productive
confident about tomorrow

Takeaway:

Git doesn’t add overhead. It removes uncertainty from data science work.

Git version control¶

Git - why bother?¶

💬

Git’s genius¶

extremely fast, distributed, decentralized
enables collaborations small to large
used for pretty much every software project
causal reasoning about code evolution
→ great for debugging

Why Git exists¶

A short origin story:

created in 2005 to manage the Linux kernel
needed to support:

fast, reliable version tracking
many contributors
parallel and nonlinear work

Key idea:
Git was designed to handle large, complex, collaborative projects — exactly what modern data science is.

First-time Git setup¶

tell Git who you are (once per machine)

git config --global user.name "Your Name"
git config --global user.email "you@example.com"

optional but useful

git config --global init.defaultBranch main

🧠 Git records who did what and when.

Creating and cloning Git repositories¶

start tracking a project: initialize a new repo

git init

get an existing project: clone an existing repo

git clone URL  # <- usually from GitHub, GitLab, ...

🧠 A Git repository is a self-contained project history.

Edit → add → commit¶

The core workflow:

edit files (e.g., vim file.py)
stage changes: add
```
git add file.py
```
record a snapshot (signed statement): commit
```
git commit -m "Explain what changed."
```

🧠 Commits are checkpoints you can return to.

Checking state & undoing mistakes¶

see what’s going on

git status  # this command shows information, great start for
            # making up your mind about next git commands

undo local changes

git restore file.py

🧠 Git constantly tells you:

what changed
what is recorded
what is still temporary

Inspecting history: log, diff, show¶

view project history

git log

see changes

git diff

inspect a specific commit

git show COMMIT_HASH

🧠 Git is a time machine with a diff viewer.

Branches: parallel worlds¶

create and switch

# short way (with optional flag "-c"):
git switch -c new-feature-experiment # (`-c` is for create)

# long way:
git branch new-feature-experiment
git switch new-feature-experiment

Why branches matter:

safe experimentation
parallel development
keep the main branch clean

🧠 Branches are cheap & safe timelines.

Merging: bringing branches together¶

merge a branch back

git switch main                   # main will be the target branch
git merge new-feature-experiment  # merges commits from feature branch

Why merging matters:

merging is used to integrate finished work
preserves the full history
avoids manual copy–paste

🧠 A merge combines timelines.

Working with others: pull, push¶

get updates (others’ new commits)

git pull  # downloads and merges from a remote computer

# check remote branches (the branch does not exist and will be created)
git checkout awesome-feature

share your work (your new commits)

git push

Git separates:

local work (your machine) ↔ shared history (the team)

Git - distributed version control¶

clients and servers fully mirror the repository
every repo clone has a full backup of all the files and all the history
enables flexible and decentralized collaboration

*Figure: Git’s distributed
design.*

Git hands-on¶

Back to the workday example¶

get ready – clone an exiting Git repository:

visit this GitLab website (in browser):
https://code.vt.edu/jrudi/linear_regression
it gives us some files to work with
find the URL to clone (blue “Code” button)
run the command to clone
cd into dirctory

git clone https://code.vt.edu/jrudi/linear_regression.git
cd linear_regression

8:30: Starting the day¶

open your laptop, see where you left off

git status

pull the latest changes

git pull

check yesterday’s changes

git log

9:45: Exploring a new idea¶

confirm the currently checked out branch

git branch  # shows all (local) branches
git status  # shows the current branch and other infos

new idea → new branch

git switch -c new-feature-experiment  # (`-c` is for create)
git branch  # confirm you're on the new branch

→ All the code written now will be separate from the main branch. You can always go back, discard the experiment, or merge the experiment into main.

11:30: Understanding history¶

an issue comes up with the main branch
switch back to it:

git switch main

check the history

git log
git show HASH  # <- one hex number shown in log
git show HASH:FILE
git diff HASH_A..HASH_B  # <- two hex numbers shown in log

14:00: Teammate pushes a bugfix¶

carfully review the changes in the teammate’s branch: (there are some typos to fix)

git pull
git diff main..teammate-fix

get the teammate’s branch and make your fixes

git checkout teammate-fix
# then: edit → add → commit

incorporate the branch into main

git switch main
git merge teammate-fix

16:00: Reproducibility check¶

Your manager gets involved:

“Can we reproduce last month’s results?”

Your answer:

“Yes, with this commit.”

you check out the exact commit

git checkout HASH

End of the day¶

Before going home

you commit and push your work:

git push  # note: does not work for "jrudi/linear_regression"

you and your teammates can continue tomorrow
nothing is lost, nothing is overwritten

Summary of commands¶

Everyday commands¶

git status 🧭
git init / clone
git add / commit
git pull / push
git diff / log / show

Every-other-day commands¶

git branch / switch / checkout
git merge

Someday commands¶

git fetch
git rebase
git remote
git stash

Key takeaways¶

Git is not about commands – it’s about:

safe experimentation
reproducibility
collaboration

Git lets data scientists move fast without loosing trust in their work.

Looking ahead¶

AI for coding
AI agents
importance of human judgement and thinking

Prepare for the next session 🌱¶

sessions/05-todo