Git & Version Control

Topics

• What is Git and why every developer uses it
• git init, git add, git commit — the core cycle
• git log, git diff, git status — understanding your history
• Branches: git branch, git checkout, git merge
• GitHub: creating repos, pushing code, pull requests
• GitHub Personal Access Tokens for Claude Code integration

Activities

• Inside your `my-first-project` folder, run `git init` to start tracking changes
• Practice the add → commit cycle with clear messages
• Create a branch, make changes, then merge it back
• Create a free GitHub account and push your project to the cloud
• Open and merge your first pull request
• Generate a GitHub Personal Access Token

Skills You'll Gain

Git fundamentals, GitHub, branching, pull requests, authentication tokens

Learning Objectives

By the end of this week, you will be able to:

1. Explain what version control is and why it matters
2. Initialize a Git repository and make commits with meaningful messages
3. View your project history using git log, git diff, and git status
4. Create branches, switch between them, and merge changes
5. Push code to GitHub and open a pull request

Lesson

The Problem Git Solves

Imagine you are writing an important essay. You save copies: "essay-draft1", "essay-draft2", "essay-final", "essay-FINAL-final", "essay-REALLY-final-v3". Sound familiar? Now imagine you need to go back to draft 2 because you accidentally deleted a paragraph in draft 4. Which file was it? When did you change it?

Git solves this problem elegantly. Instead of saving multiple copies, Git takes a snapshot of your entire project every time you tell it to. Each snapshot is called a commit. You can go back to any snapshot, compare changes between snapshots, and even work on different versions at the same time.

Think of Git like Google Docs version history, but for your entire project folder — and it works offline.

Why Git?

Git is the industry standard. Every professional developer uses it. Every company uses it. And Claude Code works best when your project is tracked by Git, because it can see your history, create branches, and help you collaborate.

The Three Areas: Working Directory → Staging → Repository

This is the most important concept in Git. Your files live in three areas:

┌─────────────────┐     git add     ┌──────────────┐    git commit    ┌────────────┐
│ Working         │ ──────────────► │ Staging Area │ ───────────────► │ Repository │
│ Directory       │                 │ (Index)      │                  │ (History)  │
│                 │                 │              │                  │            │
│ Your files as   │                 │ Files ready  │                  │ Permanent  │
│ you see them    │                 │ to be saved  │                  │ snapshots  │
└─────────────────┘                 └──────────────┘                  └────────────┘

1. Working Directory — Your actual files on disk. This is what you see when you run ls.
2. Staging Area — A holding area for changes you want to include in the next snapshot. Think of it as a loading dock where you place boxes before the truck leaves.
3. Repository — The permanent history of all your snapshots (commits). This is stored in a hidden .git folder.

Why the staging area? Because you might change 10 files but only want to save 3 of them in this particular snapshot. The staging area lets you choose.

Starting a Repository: git init

Navigate to your project folder and tell Git to start watching it:

$ cd ~/my-first-project
$ git init
Initialized empty Git repository in /Users/yourname/my-first-project/.git/

This creates a hidden .git folder inside your project. Git is now tracking this folder. You only run git init once per project.

Checking Status: git status

This is the command you will use most often. It tells you what has changed.

$ git status
On branch main
No commits yet
Untracked files:
  (use "git add <file>..." to include in what will be committed)
        README.txt
        notes/
        scripts/

"Untracked files" means Git sees these files but is not tracking them yet. They are in your Working Directory but not in the Staging Area.

Adding Files: git add

Move files from the Working Directory to the Staging Area:

$ git add README.txt
$ git status
Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
        new file:   README.txt

Untracked files:
        notes/
        scripts/

To add everything at once:

$ git add .

The . means "everything in the current folder." Now all your files are staged.

Saving a Snapshot: git commit

Create a permanent snapshot of everything in the Staging Area:

$ git commit -m "Add project structure with notes and scripts folders"
[main (root-commit) a1b2c3d] Add project structure with notes and scripts folders
 3 files changed, 0 insertions(+), 0 deletions(-)

The -m flag lets you write a message describing what changed. Good commit messages explain why you made the change, not just what. Compare:

• Bad: "Update files"
• Good: "Add project structure with notes and scripts folders"
• Bad: "Fix bug"
• Good: "Fix task list not showing completed items"

The Core Cycle

This is the rhythm of working with Git. You will repeat this hundreds of times:

1. Make changes to your files
2. git add .          (stage the changes)
3. git commit -m "Describe what and why"   (save a snapshot)

That is it. Three steps. Let us practice it.

Viewing History: git log

See all your commits (snapshots):

$ git log
commit a1b2c3d (HEAD -> main)
Author: Your Name <you@email.com>
Date:   Mon Feb 10 10:30:00 2026

    Add project structure with notes and scripts folders

For a compact view:

$ git log --oneline
a1b2c3d Add project structure with notes and scripts folders

Seeing Changes: git diff

Shows what changed since the last commit. Edit a file first, then run:

$ echo "This is my first project" > README.txt
$ git diff
diff --git a/README.txt b/README.txt
--- a/README.txt
+++ b/README.txt
@@ -0,0 +1 @@
+This is my first project

Lines starting with + are additions (green in most terminals). Lines starting with - are deletions (red). This is called a diff — you will see diffs constantly when working with Claude Code.

Branches: Parallel Timelines

A branch is a parallel copy of your project where you can experiment without affecting the original. Think of it as a forking road — you take one path, try something new, and if it works, you merge it back into the main road.

         main:        A ── B ── C ── D ── E (merged)
                              \           /
         feature:              F ── G ── H

Create a new branch and switch to it:

$ git branch add-description
$ git checkout add-description
Switched to branch 'add-description'

Or in one command:

$ git checkout -b add-description

Now any commits you make happen only on this branch. The main branch stays untouched. When you are done:

$ git checkout main
$ git merge add-description

This brings all the changes from add-description into main.

GitHub: Your Code in the Cloud

GitHub is a website that stores your Git repositories online. It is like a cloud backup for your code, plus a social platform where developers share and collaborate.

1. Go to https://github.com and create a free account.
2. Click "New repository" (the green button).
3. Name it my-first-project. Leave it public. Do NOT add a README (you already have one).
4. Follow the instructions to push your existing project:

$ git remote add origin https://github.com/yourusername/my-first-project.git
$ git branch -M main
$ git push -u origin main

git remote add origin tells Git where to push. git push sends your commits to GitHub. Refresh the GitHub page — your code is now online.

Pull Requests: Proposing Changes

A pull request (PR) is how you propose changes for review before they become official. Even when working alone, PRs are good practice:

1. Create a branch: git checkout -b improve-readme
2. Make changes and commit them
3. Push the branch: git push -u origin improve-readme
4. On GitHub, click "Compare & pull request"
5. Write a description of what you changed and why
6. Click "Create pull request"
7. Review the changes, then click "Merge pull request"

This is exactly how teams work in the real world. Claude Code can create branches and PRs for you automatically.

GitHub Personal Access Tokens

A Personal Access Token (PAT) is a special password that lets Claude Code interact with GitHub on your behalf. To generate one:

1. Go to GitHub → Settings → Developer settings → Personal access tokens → Tokens (classic)
2. Click "Generate new token (classic)"
3. Give it a name like "Claude Code"
4. Select scopes: repo (full control of repositories)
5. Click "Generate token"
6. Copy the token immediately — you will never see it again

Store it as an environment variable:

$ export GITHUB_TOKEN=ghp_xxxxxxxxxxxx

Practice Exercises

Exercise 1 (Guided): Your First Five Commits

Follow these steps exactly:

$ cd ~/my-first-project
$ git status
(should show clean working tree if you completed Week 1)

$ echo "# My First Project" > README.txt
$ git add README.txt
$ git commit -m "Add project title to README"

$ echo "Created during Week 1 of Claude Code Mastery" >> README.txt
$ git add README.txt
$ git commit -m "Add course reference to README"

$ echo "Learning: Terminal, Git, Claude Code" >> README.txt
$ git add README.txt
$ git commit -m "Add learning topics to README"

$ touch notes/week1.txt
$ echo "Week 1: Learned terminal commands" > notes/week1.txt
$ git add notes/week1.txt
$ git commit -m "Add Week 1 learning notes"

$ touch notes/week2.txt
$ echo "Week 2: Learning Git and version control" > notes/week2.txt
$ git add notes/week2.txt
$ git commit -m "Add Week 2 learning notes"

Verification: Run git log --oneline — you should see 5 commits (plus the initial one from Week 1).

Exercise 2 (Independent): Branch and Merge

Goal: Create a branch called add-scripts, add a file called scripts/greet.sh, commit it on the branch, then merge it back into main.

Hints:

• Use git checkout -b add-scripts to create and switch
• The file content can be anything (try echo 'echo Hello World' > scripts/greet.sh)
• Switch back to main with git checkout main
• Merge with git merge add-scripts

Verification: After merging, run ls scripts/ on the main branch — greet.sh should be there. Run git log --oneline to see the branch merge.

Exercise 3 (Challenge): Push to GitHub and Open a PR

Push your project to GitHub, then create a pull request:

1. Create a GitHub repository
2. Push your main branch
3. Create a new branch locally, make a change, push it
4. Open a pull request on GitHub
5. Merge the pull request

Document the GitHub URL in your notes/week2.txt file.

Self-Assessment Quiz

1. What is a commit in Git?

2. Explain the difference between git add and git commit.

3. What is a branch, and why would you use one?

4. What is a pull request?

5. What does git push do?

Answers:

1. A commit is a permanent snapshot of your project at a specific point in time. It records what every tracked file looked like when you ran git commit.

2. git add moves changes from your Working Directory to the Staging Area (preparing them to be saved). git commit takes everything in the Staging Area and saves it as a permanent snapshot in the Repository.

3. A branch is a parallel copy of your project where you can make changes without affecting the main version. You use branches to experiment, develop new features, or fix bugs safely before merging them back.

4. A pull request is a proposal to merge changes from one branch into another. It lets you (or others) review the changes before they become official. On GitHub, you create a PR by pushing a branch and clicking "Compare & pull request."

5. git push sends your local commits to a remote repository (like GitHub). It uploads your snapshots so they are backed up online and accessible to others.

Git Workflow Updates (Feb 2026)

• --from-pr flag added to resume sessions linked to a specific GitHub PR number (v2.1.27)
• Debug logs now include tool call failures and denials (v2.1.27)
• Community tip — Token optimization: The rtk (Rust Token Killer) CLI proxy can sit between Claude Code and terminal commands, filtering noise from raw command output before it reaches the LLM context (reported 89% token savings)
• Community tip — Cleaner PR reviews: When using claude-code-action in GitHub workflows, configure it to reduce comment noise and clean up old comments

Exercise:

• Try claude --from-pr 42 to resume a session tied to a specific PR
• Explore token-saving strategies for long-running sessions

Anthropic Python SDK 0.79.0 (added 2026-02-07) New release of the anthropic Python package: version... Source: https://pypi.org/project/anthropic/0.79.0/