Session 7: Git for Designers

Duration: 2 hours
Prerequisites: Sessions 1-6 completed, changes made via Claude Code
You'll need: GitHub account, GitHub Desktop installed

Part 1: Why Git Exists (15 min)

The Problem Git Solves

Imagine working on a Figma file without version history. Every change is permanent. You can't see what it looked like yesterday. If you break something, you can't go back.

That's what working with code was like before Git.

What Git Does

Git tracks changes over time. Every time you "commit," you create a save point. You can:

See what changed between any two points
Go back to any previous state
Work on something experimental without breaking the main version
Collaborate without overwriting each other's work

Why You Need It

To ship code to production, you need to:

Save your changes (commit)
Upload them to GitHub (push)
Propose they be added to the main codebase (pull request)

That's the shipping workflow. Git makes it possible.

Part 2: The 6 Concepts You Need (30 min)

Git has hundreds of commands and concepts. You need six.

1. Repository ("Repo")

A repository is a project folder that Git is tracking.

When you cloned Leigher in Session 2, you got a repo. It contains:

All the project files
The entire history of changes
Information about where it came from (GitHub)

Think of it as: A Figma file with version history enabled.

2. Commit

A commit is a save point—a snapshot of your project at a moment in time.

Each commit has:

A unique ID (like a3b5c7d)
A message describing what changed ("Add settings panel component")
The actual changes (which files changed and how)

Think of it as: Clicking "Save to Version History" in Figma with a description.

3. Clone

Cloning copies a repository from GitHub to your computer.

You already did this: git clone https://github.com/samsen-studio/leigher-v2

Now you have a complete copy—all files, all history. You can work on it locally.

Think of it as: Downloading a Figma file to work on locally.

4. Push

Pushing uploads your commits from your computer to GitHub.

After you commit changes, they exist only on your machine. Push sends them to GitHub where others can see them.

Think of it as: Syncing your local changes back to the cloud.

5. Pull

Pulling downloads commits from GitHub to your computer.

If someone else made changes and pushed them, pull gets those changes onto your machine.

Think of it as: Getting the latest version before you start working.

6. Pull Request (PR)

A pull request is a proposal to merge your changes into the main codebase.

Instead of pushing directly to the main version, you:

Create a separate branch with your changes
Open a pull request saying "here's what I changed"
Someone reviews it
If approved, it gets merged

Think of it as: Proposing changes in a Figma branch for review before merging.

Part 3: GitHub Desktop (45 min)

Why GitHub Desktop

Git was designed for command-line use. GitHub Desktop gives you a visual interface—you can see your changes, make commits, and push without typing commands.

The Interface

When you open GitHub Desktop with Leigher:

Left panel: List of changed files
Middle panel: What changed in each file (red = removed, green = added)
Bottom left: Where you write commit messages

Workflow Walkthrough

Step 1: See Your Changes

After making changes via Claude Code, open GitHub Desktop.

You'll see a list of files that changed. Click any file to see what changed inside it.

You don't need to understand the code—you're just verifying that changes happened.

Step 2: Write a Commit Message

At bottom left, there are two fields:

Summary: A short description (required) — "Add settings panel component"
Description: More detail (optional) — "Includes three toggle settings and a save button"

Write messages that describe what changed, not how.

Good: "Add user avatar to header"
Bad: "Update header.jsx and header.css"

Step 3: Commit

Click "Commit to main" (or "Commit to [branch name]").

Your changes are now saved as a commit. They're still only on your computer.

Step 4: Push

Click "Push origin" at the top.

Your commits are now on GitHub. Others can see them.

Creating a Pull Request

If you're working on a branch (recommended for real work):

Click "Create Pull Request" in GitHub Desktop
This opens GitHub in your browser
Add a title and description
Click "Create Pull Request"

Now someone can review your changes before they go into the main codebase.

Part 4: Practice (30 min)

Exercise: The Full Cycle

Let's do the complete shipping cycle, minus the review.

Step 1: Make a Change

Ask Claude:

Add a tooltip to the settings icon in the sidebar that says "Settings"

Step 2: Verify in Browser

Check localhost:5173. Does the tooltip appear? Does it look right?

Step 3: Review in GitHub Desktop

Open GitHub Desktop. You should see changed files.

Look at the changes—you'll see some code you don't understand. That's fine. You're just verifying something changed.

Step 4: Commit

Write a commit message:

Summary: "Add tooltip to settings icon"
Description: "Shows 'Settings' on hover"

Click "Commit to main".

Step 5: Push

Click "Push origin".

Step 6: Verify on GitHub

Go to github.com/samsen-studio/leigher-v2 (or your repo).

Click "Commits". You should see your commit at the top.

🎉 You just shipped code to GitHub.

Exercise: Create a Pull Request

Now let's do it with a branch.

Step 1: Create a Branch

In GitHub Desktop: Branch → New Branch
Name it: feature/add-header-search

Step 2: Make Changes on the Branch

Ask Claude:

Add a search input to the header, right side. Placeholder text: "Search surfaces..."

Step 3: Commit and Push

Same as before:

Review changes
Write commit message: "Add search input to header"
Commit
Push

Step 4: Create PR

Click "Create Pull Request" in GitHub Desktop.

On GitHub:

Title: "Add search input to header"
Description: "Adds a search field for filtering surfaces"
Click "Create Pull Request"

You now have a PR ready for review. In a real workflow, someone would approve it and click "Merge."

Git Concepts You Can Ignore (For Now)

Git has many features. Ignore these until you need them:

Rebase — Advanced merging. Not necessary.
Cherry-pick — Selecting specific commits. Not necessary.
Stash — Temporarily hiding changes. Use branches instead.
Submodules — Nested repos. Unlikely to encounter.
Tags — Marking releases. Engineering handles this.

The six concepts from Part 2 cover 95% of what you need.

When Things Go Wrong

"I can't push"

Usually means someone else pushed changes you don't have.

Fix: Click "Pull" first, then try pushing again.

"Merge conflict"

Two people changed the same thing differently.

For designers: Ask engineering for help. This is where Git gets complex.

"I committed the wrong thing"

If you haven't pushed yet: In GitHub Desktop, right-click the commit → "Undo"

If you already pushed: Ask engineering. It's fixable but requires care.

"I broke something"

Every commit is a save point. You can always go back.

In GitHub Desktop: History tab → Right-click a previous commit → "Revert changes in commit"

Session 7 Checklist

[ ] Understand the 6 Git concepts (repo, commit, clone, push, pull, PR)
[ ] Made a change via Claude Code
[ ] Reviewed changes in GitHub Desktop
[ ] Written a commit message and committed
[ ] Pushed to GitHub
[ ] Verified commit appears on GitHub
[ ] Created a branch and pull request

What's Next

Session 8: The Complete Shipping Cycle

You know all the pieces. Session 8 puts them together—you'll complete 3 full cycles from design to PR, building the muscle memory to do it smoothly.

Session 7 of 10 • The Shipping AI Designer Course
Next: Session 8 — The Complete Shipping Cycle

Git for Designers