What is Git? (for SVN users)

## Agenda

- **0:00** – Model: local-first, snapshots, graph, pointers (8 min)
- **0:08** – Exercise 0: clone the workshop repo (2 min)
- **0:10** – The 3 states: working tree / index / commits (5 min)
- **0:15** – Exercise 1: staging area (10 min)
- **0:25** – Remotes: clone, fetch, pull, push (5 min)
- **0:30** – Exercise 2: push to the shared repo (5 min)
- **0:35** – Branches and merging (7 min)
- **0:42** – Exercise 3: branch, diverge, merge (10 min)
- **0:52** – Exercise 4: controlled conflict (10 min)
- **1:02** – Undo (5 min)
- **1:07** – Exercise 5 lite: undo (3 min)
- **1:10** – Wrap-up, cheat sheet, resources (4 min)

<p class="note">Q&A pauses between sections serve as buffer.<br/>
Press <strong>Down</strong> on any slide for extra material (see next slide).</p>

Notes:
- The timings are targets, not hard deadlines. Exercises may run over; that is fine.
- Questions slides are sprinkled throughout; they serve as buffer time and keep us from running over.
- Demo: press Down now to show the audience what a reference slide looks like.

Reference: SVN → Git Rosetta Stone

Concept	SVN	Git
Repository	Central server database	Local `.git` folder (full clone)
Get the repo	`svn checkout URL`	`git clone URL` (gets full history)
Commit	Network upload to server	Local snapshot save
Publish	(same as commit)	`git push` (separate step)
Revision ID	`r1024` (sequential integer)	`a1b2c3d` (SHA-1 hash)
Branch	Directory copy, O(N)	Pointer creation, O(1)
Get changes	`svn update`	`git fetch` + `git merge` (or `git pull`)
View history	`svn log`	`git log --oneline --graph --decorate`
Undo local edits	`svn revert FILE`	`git restore FILE` (not `git revert`!)
Undo a commit	(no equivalent)	`git revert COMMIT` (new “reverse” commit)
Switch branch	`svn switch BRANCH`	`git switch BRANCH`
Who wrote this?	`svn blame FILE`	`git blame FILE`

Reference slide. Press Down for more, Right to continue

Commits and pointers

Commits A, B, C, D are immutable snapshots
main is a pointer (label) to a commit; it moves forward
HEAD points to the current branch name

Pitfall #2: A branch is a pointer, not a directory copy. Creating one is almost instant and essentially free.

Diverged branches

main points to D; topic points to F
They share history A, B, C
HEAD is on main (that is where we are working)

This is the typical state before a merge.

## Clone & push in 30 seconds

Before we get our hands dirty, two commands you need right away:

**`git clone URL`**: download a complete copy of a repository (all files, all history)
- This is the Git equivalent of `svn checkout`, but you get **everything**, not just the latest snapshot

**`git push`**: upload your local commits to the remote
- Remember: `commit` is local. `push` is what actually shares your work.

```
       clone                      commit                       push
         |                          |                           |
         v                          v                           v
     Remote  ----------------->  Your repo  ----------------->  Remote
     (download)                  (local work)                   (upload)
```

<p class="note">We will cover remotes in detail later. For now, this is all you need.</p>

Notes:
- Keep this to 30 seconds. The goal is just to de-mystify clone and push before Exercise 0 uses them.
- The full remotes section (fetch vs pull, remote-tracking refs) comes later.

## The 3 states <span class="timebox">(5 min)</span>

```text
                     "edit"                       add                    commit
        HEAD       --------->                 --------->               --------->
     (last commit)             (your "edits")             (ready to go)          (new snapshot)
     +------------+          +----------------+          +------------+          +------------+
     |            |          |                |          |            |          |            |
     |  current   |          |  working tree  |          |   index    |          |  new HEAD  |
     |  snapshot  |          |                |          |            |          |            |
     +------------+          +---+------------+          +-----+------+          +------------+
           ^                     |        ^                    |
           |   restore FILE      |        |   restore --staged |
           +<--------------------+        +<-------------------+
           (discard edits)                (unstage, keep edits)
```

<div class="warning">
<strong>Pitfall #3:</strong> The index/staging area exists and matters.
<code>git commit</code> records what is <em>staged</em>, not everything you edited.
</div>

Notes:
- This is the biggest day-to-day difference from SVN.
- In SVN, commit grabs all modifications. In Git, you choose what goes in.
- Stress: git status is your best friend. It tells you what is in each state.

## Recap: The 3 states <span class="timebox">(2 min)</span>

<div class="warning">
<strong>Pitfall #3:</strong> The index/staging area exists and matters.
<code>git commit</code> records what is <em>staged</em>, not everything you edited.
</div>

Notes:
- Quick recap from session 1. Ask: "Can someone summarize the 3 states in one sentence?"
- Remind them: git status is your best friend. Run it before every commit.
- We go straight into Exercise 1 next — no Q&A here, save questions for after the exercise.

## Exercise 1: the staging area is real <span class="timebox">(10 min)</span>

**Goal:** See the difference between working tree, staged, and committed.

<div class="predict">
<strong>Pause and predict (1 min):</strong> After you run the commands below,
what will <code>git status</code> show? Which changes will be "staged" and which "unstaged"?
</div>

**Commands.** Run these one at a time, read `git status` after each:

```bash
echo "Line 2" >> notes.txt
git status                 # unstaged change
git diff                   # shows Line 2 as unstaged

echo "Line 3" >> notes.txt
git add notes.txt          # stages BOTH Line 2 and Line 3
git status                 # everything staged
```

<p class="continued-tag">Exercise continues below. Press Down</p>

Notes:
- Walk through slowly. Make them read git status output aloud if possible.
- The key insight: git add snapshots the file into the index at that moment.
- When they first run git status, they will see "Your branch is up to date with 'origin/main'." Acknowledge it briefly: "This just means your local main matches what you downloaded. We will explain origin/main in the Remotes section."

## Questions <span class="timebox">(2 min)</span>

You have now used the 3 states. What surprised you?

- Did `git status` show what you predicted?
- What happens if you run `git commit` with nothing staged?
- Your colleague says "I committed the fix." In SVN, would you have it? In Git?
- After `git add`, you edit the file again. What does `git commit` record: the version you added, or the latest edit?

</div>

Notes:
- Covered so far (new since last Q&A): clone & push preview, Exercise 0 (hands-on clone, saw origin, git log, git branch), The 3 states (Pitfall #3: staging area exists, git add stages, git commit records staged, restore, restore --staged), Exercise 1 (staging area hands-on — saw file in both staged and unstaged, committed only staged, Line 4 left behind), debrief (SVN commit = publish; Git commit = local, push = publish).
- Common surprise: the file appearing in both staged and unstaged sections.
- If someone asks about git commit -a: mention it exists (skips staging), but discourage it for learning.

Two separate graphs (2 min)

After git clone, your machine has its own DAG. The remote “origin” has its own.

Your machine

Remote “origin” (GitHub)

origin/main is a local pointer, not a live link
git status says “up to date” — it compares locally only, does NOT contact the server
Only git fetch / git pull actually talks to the remote

Don’t be fooled: git status can say “up to date” even when the remote is 50 commits ahead. Run git fetch first if you want the truth.

Press Down for a step-by-step example of the push/pull cycle.

Example: the push/pull cycle (1/7)

After clone: both machines are identical. Everything is in sync.

Your machine

Remote “origin” (GitHub)

main and origin/main both point to C. You and the remote agree.

Press Down to continue, Right to skip ahead

Example: the push/pull cycle (2/7)

Your colleague commits and pushes D. The remote moves forward.

Your machine

Remote “origin” (GitHub)

Your machine has no idea that D exists.

origin/main still points to C — that is where the remote was when you last fetched.

Press Down to continue, Right to skip ahead

Example: the push/pull cycle (3/7)

You commit E locally. git status says “ahead of origin/main by 1 commit.”

Your machine

Remote “origin” (GitHub)

The two graphs have diverged, but you do not know it yet.

git status thinks you are simply 1 commit ahead — it has no idea the remote also moved.

Press Down to continue, Right to skip ahead

Example: the push/pull cycle (5/7)

git fetch downloads D and updates origin/main. Your files are untouched.

Your machine

Remote “origin” (GitHub)

Now you can see the divergence. main is at E, origin/main is at D.

Press Down to continue, Right to skip ahead

Example: the push/pull cycle (6/7)

git pull merges D and E into a new merge commit M.

Your machine

M has two parents (D and E). Your work and your colleague’s work are combined.

Press Down to continue, Right to skip ahead

Example: the push/pull cycle (7/7)

git push succeeds. Both machines are back in sync.

Your machine

Remote “origin” (GitHub)

main and origin/main both point to M. Everyone has everything.

Reference slide. Press Right to continue

## Remotes: the daily cycle <span class="timebox">Remotes (5 min)</span>

As we just saw, `origin/main` is your local record of where the remote was.
Here is the full daily cycle:

git pull           =  git fetch  +  git merge origin/main   (default)
  git pull --rebase  =  git fetch  +  git rebase origin/main  (recommended)
```

- `origin/main` is your **local record** of where the remote's main was at last fetch
- `git fetch`: updates remote-tracking refs only (safe, no changes to your work)
- `git pull`: fetch + integrate (merge or rebase, depending on config)
- `git push`: publishes your commits to the remote

<div class="warning" style="text-align: left;">
<strong>Pitfall #4:</strong> <code>git fetch</code> vs <code>git pull</code>.
Fetch is safe and read-only. Pull also changes your branch.<br>
<strong>Pitfall #5:</strong> <code>git pull</code> by default uses merge commits, cluttering your log.<br>
Fix: <code>git config --global pull.rebase true</code>.
</div>

Notes:
- Builds on the "Two separate graphs" slide: they now know origin/main is local.
- They already cloned in Exercise 0, so "origin" is not abstract — they have it.
- SVN's "svn update" does both fetch and merge in one step. Git lets you separate them.
- Recommend: fetch first, inspect, then decide whether to merge.
- Pitfall #5: pull.rebase only rewrites commits that haven't been pushed yet, so it is safe for normal daily use. But warn them: if they ever have local merge commits or complex branch history, rebase can get confusing. For this group's workflow (everyone on main), it is the right default.

Reference: remote-tracking refs

Remote “origin”:

Your local repo after fetch:

After git merge origin/main (or git pull):

origin/main updates only on fetch (or pull, which fetches first)
You cannot commit directly to origin/main
git branch -vv shows tracking relationships

Reference slide

## Exercise 2: push to the shared repo <span class="timebox">(5 min)</span>

**Goal:** Experience the commit → push → rejected → pull → push cycle.

Your Exercise 1 commit is still local. First, discard the leftover Line 4:

```bash
git restore notes.txt      # discard unstaged Line 4
```

Now let's share your work and add a personal file:

```bash
echo "Hello from <your name>" > yourname.txt
git add yourname.txt
git commit -m "Add yourname.txt"
git push
```

**If push is rejected** (someone else pushed first):

```bash
git pull               # fetch + merge their changes
git push               # try again — repeat if needed
```

This should merge cleanly because you all edited different files.

<div class="failure-mode">
<strong>Common failure:</strong> Push rejected and you panic.
This is normal! It means the remote has new commits you don't have yet.
<code>git pull</code>, then <code>git push</code> again.
</div>

Notes:
- This is the realistic SVN-to-Git experience: everyone pushing to main.
- The rejected push is a feature, not a bug. It prevents overwriting others' work.
- Everyone's "Add lines 2 and 3" commit has identical content, so git pull should auto-merge cleanly.
- If someone gets a merge conflict on notes.txt, help them resolve it (preview of Exercise 4).

### Reference: answers

**Why was push rejected?**
- The remote had commits you did not have (someone pushed before you). Git refuses to overwrite them.
- `git pull` fetches those commits and merges them into your branch. Then you can push.

**`origin/main` vs `main`?**
- `main` is your local branch. You commit to it, it moves forward.
- `origin/main` is a read-only local record of where `main` was on the remote the last time you ran `git fetch` or `git pull`.
- They can diverge: you commit locally (main moves), but origin/main stays put until the next fetch.

**After `git fetch`, are your files updated?**
- No! Fetch only updates `origin/main` (the remote-tracking ref). Your working tree and your local `main` are untouched.
- To update your files, you need to merge: `git merge origin/main` (or use `git pull`, which does both).

**What if two people edit the same line and both push?**
- The first push succeeds. The second is rejected.
- After `git pull`, Git will report a **merge conflict**. You resolve it by hand. We will practice this in Exercise 4.

<p class="reference-tag">Reference slide. Press Right to continue</p>

## Branches: cheap pointers <span class="timebox">Branches (7 min)</span>

A branch is a name pointing to a commit. Creating one is instant.

**Switching branches:**
- Moves HEAD to a different pointer
- Updates your working tree to match that snapshot

```bash
git branch             # list branches (star marks current)
git switch -c topic    # create branch "topic" and switch to it
git switch main        # switch back to main
```

<div class="warning">
<strong>Pitfall #6:</strong> New branches only exist on your machine until you push.
In SVN, branching is a server operation visible to everyone immediately.
In Git, <code>git push -u origin branch-name</code> publishes the branch
and sets up tracking so future <code>git push</code> just works.
</div>

<p class="small">Older tutorials and Stack Overflow answers use <code>git checkout</code> /
<code>git checkout -b</code>. Same thing; <code>switch</code> is the modern replacement.</p>

Notes:
- Contrast with SVN: svn copy creates a server-side directory. Git branch writes 41 bytes.
- Mention: git branch (no args) lists branches; git branch -d name deletes one.
- Pitfall #6: the first time they push a new branch, git will refuse with a message about setting an upstream. The -u flag fixes this and only needs to be done once per branch.

Reference: merge vs fast-forward

Fast-forward (topic is ahead of main, no divergence):

Before:

After:

No new commit is created. main pointer simply moves forward.

Merge commit (main and topic have diverged):

Before:

After:

M is a new commit with two parents.

Reference slide

Merge: combining histories

Two outcomes when you run git merge topic:

Fast-forward (no divergence): main pointer moves to the topic commit. No new commit created.

Merge commit (branches diverged): a new commit with two parents is created.

Pitfall #7: Unlike svn merge (which replays changes one at a time), Git merge combines two snapshots into one. The result is a new commit with two parents.

## Undo menu (safe subset) <span class="timebox">Undo (5 min)</span>

**Discard unstaged edits** (revert file to last staged/committed state):
```bash
git restore FILE
```

**Unstage** (keep edits in working tree):
```bash
git restore --staged FILE
```

**Undo a commit** (safe for shared history, creates a new "reverse" commit):
```bash
git revert <commit>
```

<div class="warning">
<strong>Pitfall #8: <code>svn revert</code> ≠ <code>git revert</code>.</strong><br>
<code>svn revert</code> = discard local edits → in Git that is <code>git restore</code>.<br>
<code>git revert</code> = create a new commit that undoes an old commit.
</div>

<div class="warning">
<strong>Pitfall #9: history rewrite is dangerous.</strong><br>
<code>git reset --hard</code> and <code>git rebase</code> rewrite history.
If others have your commits, this causes pain. Prefer <code>git revert</code>.
</div>

Notes:
- Stress the naming trap: svn revert ≠ git revert. This WILL confuse people.
- restore is the safe daily tool. revert is the safe published-history tool.
- reset and rebase are covered in one "danger zone" slide next.

## Working rules (so Git stays pleasant)

- Make small commits with clear messages
- Branch early, merge often
- Run `git status` before every commit
- Add a `.gitignore` early (keep build artifacts out of the repo)
- When syncing: prefer `fetch` first, then decide how to integrate
- Avoid rewriting shared history unless your team explicitly does that
- When in doubt: `git status`, `git log --oneline --graph --decorate --all`

<div class="warning">
<strong>Pitfall #10:</strong> <code>git add .</code>, <code>git add -A</code>,
and <code>git commit -a</code> stage <em>everything</em>.
You will accidentally commit build artifacts, editor backups, or temporary files.
Always <code>git add</code> specific files by name, and set up a
<code>.gitignore</code> early (see reference slide below).
</div>

Notes:
- These are habits, not commands. The goal is to develop good intuition.
- Mention .gitignore briefly here; the reference slide below has a starter template.
- Pitfall #10: SVN users who discover git commit -a will treat it as "the SVN way" and skip staging entirely. This works until they commit a 500MB build artifact.

## Take-home cheat sheet

```
INSPECT       git status                          your compass
              git diff / git diff --staged        unstaged / staged changes
              git log --oneline --graph --decorate --all
              git blame FILE                      who changed each line

STAGE/COMMIT  git add FILE                        stage changes
              git commit -m "msg"                 local snapshot
              git push                            share with remote

BRANCHES      git switch -c NAME                  create + switch
              git switch NAME                     switch
              git merge BRANCH                    integrate

SYNC          git clone URL                       get the repo (first time)
              git fetch                           download (safe)
              git pull                            fetch + merge
              git push                            upload

UNDO (safe)   git restore FILE                    discard unstaged edits
              git restore --staged FILE           unstage
              git revert COMMIT                   undo commit (new commit)

UNDO (danger) git reset / git rebase              rewrites history!
```

Full survival guide: [edgarcosta.org/talks/git-survival-guide/](/talks/git-survival-guide/)

Notes:
- Encourage them to keep the survival guide visible for the first few weeks.
- The full document covers: .gitignore, revision numbers, merge vs rebase policy,
  undo cookbook, semantic linefeeds for LaTeX, recommended config.