In this post:
- What is GitHub (actually)?
- Repositories: your product's source of truth
- Branches: your safe space to build
- Commits: saving snapshots of your work
- Pull requests: submitting code for review
- The PR review cycle: from draft to merge
- How to set up a design-to-code workflow with your team
What is GitHub (actually)?
GitHub is a cloud platform where your entire product's codebase lives and where your team collaborates on changes to that code. Think of it as the single source of truth — the place where approved, production-ready code is stored and managed.
The core concept is simple: you work on code locally (on your own machine), and when you're ready, you push your changes up to GitHub. Your team reviews what you've done, and if everything looks good, those changes become part of the live product.
That's it. Everything else — repos, branches, commits, pull requests — is just the structure that makes this process organized and safe.
GitHub vs. Figma version history
If you're coming from a design background, you already understand version control intuitively. Figma saves your version history automatically. GitHub does the same thing for code, but you control when and how versions are saved. Instead of Figma's autosave, you're deliberately creating checkpoints (called commits) as you work. It's more intentional, but the mental model is similar.
GitHub vs. just emailing code around
Without GitHub, sharing code changes would be chaos — like passing a Figma file back and forth as email attachments instead of sharing a link. GitHub gives everyone one shared, always-up-to-date version while letting individuals work on their own copies safely.
Repositories: your product's source of truth
A repository (or "repo") is the full codebase for a project, stored on GitHub. When your company gives you access to their GitHub, you'll see one or more repositories — each one representing a product, a website, or a specific part of the tech stack.
Your local setup is a copy of this repo downloaded to your machine. You make changes locally, and when you're ready, you push those changes back up to the shared repo. Everyone on the team is working from this same repo, pushing their changes into it.
If you haven't set up your local environment yet, do that first. You'll need Git installed, access to your company's GitHub, and your editor connected to the repo.
Branches: your safe space to build
Here's the concept that made everything click for me: branches.
The main branch is the live product. It's what's approved, what's real, what your users see. As a designer pushing code, you do not want to touch the main branch directly. Ever.
Instead, every time you start a new feature, you create a branch. A branch is basically a copy of the entire main codebase that you can build on top of without affecting anything that's live. You can mess things up, experiment, delete things, go wild — and nothing on the main branch is affected.
In practice, this looks like:
- You're tasked with redesigning the onboarding flow
- You create a branch called
feature/onboarding-redesign - You build the entire new UI on that branch
- When it's ready, you submit it for review (more on this below)
- Once approved, your branch gets merged into main and the feature goes live
Branch naming conventions
Before creating your first branch, ask your team: "Is there a naming convention for branches?" Most teams follow a pattern like type/short-description — for example, feature/onboarding-flow or fix/nav-alignment. Getting this right from the start saves you from awkward rename conversations later.
The mistake I made early on
When I was getting started, I didn't always check which branch I was on before working. I'd start building, realize I was on the wrong branch, and have to restart. Now the first thing I do before writing any code is confirm I'm on the right branch. It takes two seconds and saves hours.
Commits: saving snapshots of your work
A commit is a saved snapshot of your code at a specific point in time. Think of it like hitting "save" in a game — if anything goes wrong after that point, you can always go back to your last commit.
As you're building a feature on your branch, you want to commit regularly. Finished the header layout? Commit. Got the form working? Commit. Every time you reach a stable point, save that progress.
Here's the important distinction: committing saves to your local machine only. It doesn't push anything to GitHub yet. Nobody on your team can see your commits until you explicitly push them. This means you can commit freely, experiment, and only share your work when you're actually ready.
A good commit habit looks like this:
- Make a meaningful chunk of progress
- Commit with a short description of what you did (e.g., "Add onboarding step indicators")
- Keep building
- Repeat
Don't wait until the whole feature is done to commit. Small, frequent commits give you more restore points if something breaks.
Pull requests: submitting code for review
A pull request (or PR) is how you formally submit your code for your team to review. Once you've been building on your branch, committing as you go, and you feel good about the work — it's time to create a PR.
A pull request is essentially saying: "Hey team, here's what I built. Take a look, give me feedback, and when everyone's happy, let's merge this into the main branch."
Keep your PRs small
This is the lesson I learned the hard way. I once built an entire feature — back and forth, iterating for days — and when I submitted the PR, it changed over 2,000 lines of code. My engineers took one look and said, "We can't review this."
The standard at most companies is to keep PRs under 50 lines of changed code. That sounds tiny, but it forces you to break features into smaller, reviewable chunks. One PR for the layout. Another for the form logic. Another for the API integration.
If you're building something big, plan your PRs upfront. Before you start coding, map out how the feature can be broken into 3-5 small, sequential pull requests. This makes life easier for everyone — your reviewers get digestible chunks, and you get faster feedback.
What makes a good PR
Before submitting, check if your team has a PR checklist or template. Most engineering teams define their expectations in a README or contributing guide. Common requirements include:
- A clear title describing what changed
- Context on why the change was made
- A test plan explaining how to verify it works
- Screenshots or screen recordings of UI changes
That last one is something I always add, even when it's not required. I include before and after screenshots directly in the PR description. It gives reviewers instant visual context without having to pull the code and run it locally.
Preview links are a game changer
If your team uses a deployment platform like Vercel, your PRs might automatically generate a preview link — a temporary URL where anyone can see and test your changes live, without downloading any code. If your company doesn't have this set up, it's worth pushing for. It completely changes how fast feedback happens.
The PR review cycle: from draft to merge
Once your PR is submitted, here's what the typical cycle looks like:
- Draft PR — You submit the PR as a draft while you're still polishing. This signals to the team that it's not ready for review yet but gives them visibility into your progress.
- Mark as ready — When you're confident in the work, you mark the PR as ready for review. Most repos have branch protection rules that prevent anyone from merging until the PR is reviewed and approved.
- Engineer review — A team member (usually an engineer) reviews the code. They'll look at the "Files changed" tab, which highlights exactly what you added, modified, or removed. They leave comments directly on specific lines of code.
- Address feedback — You go back to your code, pull the comments from the PR, make the requested changes, and push updates. The PR automatically reflects your new commits.
- Approve and merge — Once everyone is satisfied, the PR gets approved and merged into the main branch. Your feature is now part of the live product. The branch is closed, and you start the cycle again with a new feature.
This back-and-forth between designer and engineer is where the real collaboration happens. It's not just about code review — it's a conversation about quality, consistency, and user experience.
How to set up a design-to-code workflow with your team
If your team doesn't have a clear process for designers submitting code, here's how to build one. This is exactly the kind of workflow we help teams establish at TDP when we're working with B2B SaaS companies shipping product.
1. Define branch and PR conventions together
Sit down with your engineering team and agree on naming conventions for branches, PR title formats, and what information should be included in every PR description. Document this in a shared file in the repo (usually CONTRIBUTING.md). Having these standards means non-technical contributors know exactly what's expected.
2. Set up a PR checklist
Create a PR template that lives in the repo. Every time someone opens a PR, the template auto-populates with the required sections — description, test plan, screenshots, related tickets. This eliminates guesswork and makes reviews faster.
3. Establish a review process
Decide who reviews designer PRs and what the turnaround expectation is. Some teams assign a dedicated "design PR buddy" on the engineering side. Others rotate reviewers. Whatever you choose, make it explicit so PRs don't sit in limbo.
4. Set up preview deployments
If you're using Vercel, Netlify, or a similar platform, configure automatic preview deployments for every PR. This single change dramatically speeds up the review process because reviewers can see the actual UI without pulling code locally.
5. Start small and iterate
Don't try to ship a full feature redesign as your first PR. Start with something small — fix a color, adjust spacing, update copy. Get comfortable with the commit-push-PR-review-merge cycle on low-stakes changes before tackling larger features.
The goal isn't to make designers into engineers. It's to give designers enough fluency with the tools that the handoff between design and development becomes seamless — or disappears entirely.
Tools and resources
- GitHub Desktop — If the command line feels intimidating, GitHub's desktop app provides a visual interface for commits, branches, and PRs. [EXTERNAL LINK: GitHub Desktop]
- VS Code + GitHub extension — VS Code has built-in Git support and a GitHub PR extension that lets you review and manage PRs without leaving your editor. [EXTERNAL LINK: VS Code GitHub Pull Requests extension]
- Claude Code — If you're using AI to help write code, tools like Claude Code can help you create commits, generate PR descriptions, and even pull review comments directly into your editor. [EXTERNAL LINK: Claude Code]
If your team is trying to figure out how designers and engineers can collaborate on code more effectively, that's exactly what we work on at TDP. We run workshops with product teams to establish a design-to-code workflow — from environment setup through PR process — so your designers can start shipping alongside engineers. [INTERNAL LINK: TDP workshops]
Start shipping
GitHub isn't just an engineering tool anymore. If you're a designer who's writing code — or planning to start — understanding repos, branches, commits, and PRs is the foundation of everything. You don't need to master the command line or memorize Git commands. You just need to understand the workflow and build good habits around committing early, branching correctly, and keeping PRs small.
The first PR is the hardest. After that, it becomes muscle memory.
[INTERNAL LINK: Book a workshop to set up your team's design-to-code workflow]
