Git for designers - understanding Bitbucket and GitHub
March 2026
🎨 Git for Designers
A plain-English guide to understanding GitHub, Bitbucket, and how they fit into our AI-powered design workflow.
Written for designers. No coding experience required.
What Even Is Git?
Imagine you're working on a poster in Figma. You duplicate the artboard before trying a wild idea — that way you can always go back. Now imagine doing that automatically, for every tiny change, with a full history you can scroll through like a timeline.
That's Git. It's a version control system — a tool that keeps a complete history of every change anyone makes to a project's files. Think of it like an infinite undo button that works across your whole team.
Key thing to remember: Git is the engine. GitHub and Bitbucket are the cars built on that engine. They give you a nice dashboard, buttons, and a place to park your work online.
GitHub vs Bitbucket — What's the Difference?
Think of them like Figma vs Sketch — they do roughly the same job, but each has its own vibe and ecosystem.
| GitHub | Bitbucket | |
|---|---|---|
| Owned by | Microsoft | Atlassian (the Jira people) |
| Best known for | Open source, huge community | Tight integration with Jira & Confluence |
| Vibe | Social media for code — profiles, stars, followers | Workplace tool — built for corporate teams |
| Why our team might use it | Sharing public work, open-source projects, community plugins | If we use Jira for project management and want everything connected |
The bottom line: They're both "Google Drive for code." Which one you use usually depends on what other tools your company is already using. If your team says "check the repo," they mean "look at our project folder on GitHub/Bitbucket."
The Words You'll Hear (and What They Actually Mean)
The Basics
- Repository (Repo) — A project folder. It holds all the files plus their entire edit history. Like a Figma file, but for code.
- Clone — Downloading a copy of a repo to your computer. Like "Make a copy" in Google Drive.
- Commit — A save point. Every commit is a snapshot of the project at that moment, with a little note describing what changed. Think of it like "Version 12 — updated hero section."
- Push — Uploading your saved changes from your computer to the online repo. Like hitting "sync" in Dropbox.
- Pull — Downloading the latest changes from the online repo to your computer. The opposite of push.
Branching (This is the Big One)
- Branch — A separate copy of the project where you can make changes without messing up the main version. Like duplicating your Figma page to try something experimental.
- Main (or Master) — The "official" branch. This is the live, approved version. Nobody works directly on main — you always work on a branch.
- Merge — Taking the changes from your branch and combining them into main. Like deciding your experimental Figma page is better and replacing the original.
- Pull Request (PR) — A formal "hey team, I'd like to merge my changes" request. It lets other people review your work before it goes live. Bitbucket calls these Merge Requests — same thing, different name.
When Things Get Spicy
- Conflict — When two people changed the same thing and Git doesn't know which version to keep. Like two designers editing the same component at the same time. Someone has to decide which version wins.
- Diff — A side-by-side comparison showing exactly what changed. Red = removed. Green = added. Very satisfying to look at.
- Stash — Temporarily hiding your unfinished work so you can look at something else. Like putting your messy sketch in a drawer before a client walks in.
Why Should Designers Care?
You might be thinking, "I live in Figma. Why do I need to know this?" Here's why:
- Your design tokens, CSS, and component code live in repos. Understanding where they are helps you find and reference them.
- Pull requests are where decisions happen. Developers discuss changes, leave comments, and approve work in PRs. If you can read a PR, you can catch visual issues before they go live.
- Branches tell you what's in progress. If a dev says "it's on the feature/new-nav branch," you know that work hasn't been merged into the live product yet.
- AI tools interact with repos directly. Our new AI workflow (see below) reads and writes code from these repos. Understanding the flow helps you guide the AI better.
Our AI-Powered Design-to-Code Process
This is where things get exciting. We use AI tools to bridge the gap between design and code, and they all interact with Git.
The Tools
Cursor Think of Cursor as a code editor (like VS Code) with an AI copilot built in. A developer — or even a designer — can describe what they want in plain English, and Cursor suggests or writes the code.
- "Make this button rounded with a 4px border radius and our brand blue"
- "Create a responsive card component that matches this layout"
Cursor works with files that live in a Git repo, so every change it helps create goes through the same branch → commit → PR flow.
Claude Code Claude Code is a command-line tool (that black-screen-with-text thing) where you can have a conversation with Claude and it directly edits your project files. It can read your entire codebase, understand the structure, and make changes across multiple files at once.
Think of it like having a developer sitting next to you who can instantly understand your whole project and make changes you describe in plain English.
How It All Fits Together — The Workflow
Here's what a typical cycle looks like when we use AI tools in our design process:
┌─────────────────────────────────────────────────────────┐
│ │
│ 1. DESIGN │
│ You create or update designs in Figma │
│ │
│ ↓ │
│ │
│ 2. BRANCH │
│ A new branch is created in the repo │
│ (e.g., feature/updated-hero-section) │
│ │
│ ↓ │
│ │
│ 3. AI BUILDS │
│ Using Cursor or Claude Code, changes are │
│ made to match your designs. The AI reads │
│ your design specs and writes the code. │
│ │
│ ↓ │
│ │
│ 4. COMMIT & PUSH │
│ The AI-generated code is saved (committed) │
│ and uploaded (pushed) to the branch. │
│ │
│ ↓ │
│ │
│ 5. PULL REQUEST │
│ A PR is opened. This is where YOU come in — │
│ review the visual output, leave comments, │
│ request changes. │
│ │
│ ↓ │
│ │
│ 6. REVIEW & ITERATE │
│ AI tools can make revisions based on your │
│ feedback. New commits are added to the │
│ same branch and PR. │
│ │
│ ↓ │
│ │
│ 7. MERGE │
│ Once approved, the branch is merged into │
│ main. Your design is now live. │
│ │
└─────────────────────────────────────────────────────────┘
Your Role in This Process
You don't need to write code or use the terminal. Here's what to focus on:
- Provide clear design specs. The better your handoff (spacing values, colour tokens, interaction notes), the better the AI output.
- Review PRs visually. Most PRs include preview links or screenshots. Check that the implementation matches your design.
- Leave comments on PRs. "The padding here should be 24px, not 16px" is exactly the kind of feedback that AI tools can action immediately.
- Understand branch names. When someone says "it's on
feature/new-checkout," you know that's a work-in-progress branch, not the live site.
What Makes AI Tools Different from Traditional Development?
| Traditional | AI-Assisted | |
|---|---|---|
| Speed | Developer writes every line manually | AI generates a first draft in seconds, developer refines |
| Iteration | Feedback → developer re-codes → new PR | Feedback → AI re-generates → new commit (much faster) |
| Your involvement | Often limited to handoff and final QA | You can be involved throughout, giving feedback at every step |
| Communication | "Can you make this 2px bigger?" via Slack | Same request, but it can be actioned by AI in real-time |
Quick Reference — Common Scenarios
"Where do I find the latest code for the homepage?"
→ Look at the main branch of the repo. That's always the current live version.
"A developer said my component is 'in review' — what does that mean?" → There's an open Pull Request. The code exists on a branch but hasn't been merged into main yet. You might be asked to review it.
"Someone asked me to 'check the diff' — what do I look at?" → Open the Pull Request on GitHub/Bitbucket. Click on "Files changed." You'll see a side-by-side comparison with red (removed) and green (added) highlights.
"I found a bug on staging — how do I report it?" → Find the relevant Pull Request or open an Issue in the repo. Describe what you see vs. what you expected, and include a screenshot.
"The AI tool made a change I don't like — can we undo it?" → Yes! That's the beauty of Git. Every commit is a save point. The team can revert (undo) any commit and go back to a previous version.
Tips for Working with Technical Teams
- Don't be afraid of repos. You can browse them on GitHub/Bitbucket in your browser — no terminal needed. It's just folders and files.
- Star or watch repos you care about. You'll get notifications when things change.
- Learn to love PRs. They're the single best place to catch design issues before they reach users.
- Ask about the branch. "Which branch is this on?" is a perfectly normal question that instantly tells you how close something is to going live.
- Preview links are your friend. Many teams set up automatic preview links for every PR. Bookmark them.
Last updated: March 2026. This is a living document — suggest edits any time.