A Plain-Language Guide
GitHub can feel like it was built for everyone except you. It wasn't. Here's what actually matters for design work — in language that doesn't assume you're an engineer.
Start reading →You don't have to use GitHub to design. But your work increasingly lives near it.
The goal isn't to turn you into a developer. It's to let you read what's there, leave good feedback, and make small changes without breaking anything.
Forget the jargon for a moment. GitHub is a shared folder with a perfect memory and a polite way of merging everyone's edits.
Five ideas cover almost everything.
The project folder. It holds all the files plus the entire history of every change ever made.
A saved snapshot with a short note attached. Like a named version in a design tool's version history, but you decide when and what to save.
A parallel copy of the project where you can experiment without touching the live version. The main branch is the source of truth.
"Here are my changes — please review and merge them in." This is where discussion, feedback, and approval happen. It's the most important place for a designer to be.
Accepting a branch's changes into main. The polite-merging part.
If you understand those five, you understand 90% of what you'll see.
You have three ways in, and you do not need the scary one to start.
Read files, browse history, review pull requests, leave comments, and make small edits right in the browser. Most of a designer's day can happen here.
A free app that handles file-syncing without typing commands. Use this when you're editing actual files (tokens, SVGs, copy) on your own machine. This is the sweet spot for most designers.
The powerful, intimidating option. Worth learning eventually, but skip it for now. Everything above works without it.
Recommendation: start on the website, install GitHub Desktop when you need to edit files locally.
Say you need to fix a hardcoded colour in a button component.
main. Name it something clear like fix/button-hover-colour.
main. Done.
The whole loop: branch → edit → commit → push → PR → merge. You'll repeat it forever.
On a PR, the Files changed tab shows old vs. new side by side. Click any line to leave a comment — perfect for "this spacing should be 16px, not 12px" pinned to the exact spot. Use Start a review to batch comments instead of firing them off one at a time.
For tiny changes (a typo, a copy tweak, a colour value), click the pencil icon on any file. GitHub walks you through committing it — you can even let it create the branch and PR for you automatically. No app required.
An issue is a tracked note: a bug, a request, an idea. Think of it as a ticket with a comment thread. Great for "the focus state is missing on the dropdown" when you're not the one fixing it.
Need an icon or file from a repo? Open it and use the download button. For the whole project, the green Code button has a "Download ZIP" option.
main unless you're certain. Branches exist so mistakes stay private.Commit saves locally; push uploads it. In GitHub Desktop they're two separate buttons, and forgetting to push is the classic "but I saved it!" moment.
They happen when two people edit the same lines. They look alarming but just mean "a human needs to choose which version wins." Ask a developer the first time — it's a five-minute fix, not a disaster.
Browsing, reading, and downloading change nothing. The only actions that alter anything are commits and merges, and even those are reversible.
READMEs, issues, and PR descriptions all use it. Learn five things — headings, bold, lists, code, and links — and you'll write like a native.
| Term | Plain meaning |
|---|---|
| Repository | The project folder, with full history |
| Branch | A safe parallel copy to work in |
| Commit | A saved snapshot with a note |
| Push | Upload your commits to GitHub |
| Pull request | "Review and merge my changes, please" |
| Merge | Accept changes into the main version |
| Issue | A tracked note, bug, or request |
| README | The file that explains the project |
main | The official, live version of the project |
Once the workflow above feels natural, the genuinely useful next steps are: learning enough Markdown to write clean PRs and issues, getting comfortable reading a diff (the red/green old-vs-new view), and eventually picking up a handful of command-line basics so you're not dependent on the app.
None of that is urgent. Being able to review a PR thoughtfully is worth more than any terminal trick.
You're not trying to become an engineer. You're trying to be the designer whose feedback lands in the right place, whose small fixes don't need a ticket, and who can read what the team is building. That starts the moment you open your first pull request.