A designer’s guide to using GitHub without fear.

The first time someone told me to “just commit and push,” I nodded like I understood and quietly panicked. Git looked like a language made entirely of warnings: detached HEAD, merge conflict, force push. Every one of those sounded like something I could break and never get back, so for years I kept my distance and saved my projects in folders named final, final-2, and final-actually.

Then the ground shifted. You don’t have to memorize git anymore, because your agent types the commands. What you actually need is the picture in your head: what a repo is, what a commit saves you from, which moves are safe and which ones quietly delete your afternoon. Once that picture is there, the wall turns back into a tool.

This is a designer’s onramp to GitHub. No git background, no terminal fluency. By the end you’ll have an account, one real repo, a habit that sticks, and an agent that runs the version control for you and tells you what it did in plain English.

These two words get used interchangeably and that’s most of the confusion. Git is the tool that runs on your Mac and records the history of a project: every save point, what changed, and the ability to travel back to any of them. GitHub is a website that stores a copy of that history in the cloud, so it’s backed up, reachable from any machine, and shareable with other people (or other agents).

You can use git with no internet and never touch GitHub. But the moment you want a backup, a second device, or a place an agent can pull from, GitHub is the home you push to.

Why a designer specifically should bother:

• You can undo anything. Every commit is a save point. Broke the layout an hour ago? Roll back to before you broke it, exactly, without trying to remember what you changed.
• You stop losing work. The folder named final-actually goes away. There is one project, with its whole history inside it, backed up off your machine.
• You can work across machines. Push from your Mac, pull on another. This is how a project edited in Claude Code on your desktop stays in sync with Claude Code on your iPhone.
• Agents can work safely. When your code is committed, you can let Claude Code or Codex make bold changes, because anything they break is one rollback away.
• It’s how things ship. Hosts like Vercel watch a GitHub repo and deploy automatically every time you push. Your repo becomes the deploy button.

A Mac, a free GitHub account, and git itself. On a Mac, git almost always comes along with the Xcode Command Line Tools, so there’s a good chance it’s already there. Check in Terminal (Spotlight with ⌘space, type “Terminal”):

If it prints a version number, you’re set. If macOS instead offers to install the command line tools, accept it, or run xcode-select --install and wait a few minutes.

Beyond that, two optional tools make everything smoother: the GitHub CLI (gh), which handles sign-in and creating repos in one line, and optionally GitHub Desktop if you ever want a visual view of your history. We’ll install gh in the next step. I’m assuming Claude Code or Codex is already installed and signed in; if not, that’s a short detour and you can come back.

First, the account: go to github.com, sign up, pick a username you won’t be embarrassed by (it shows up in every repo URL), and verify your email. The free tier is genuinely all you need, including unlimited private repos.

Then authentication, which is the step that scares people off and shouldn’t. Authenticating just means proving to GitHub that your Mac is allowed to push code to your account. The GitHub CLI makes this one command that opens your browser and does the rest:

If you don’t have Homebrew, the gh install page has a one-click installer. When you run gh auth login, it asks a few questions. Here are the answers that keep it simple:

1. 01Choose GitHub.com (not Enterprise).
2. 02Choose HTTPS as the protocol. It’s the simplest path, and the one I use.
3. 03When asked to authenticate, choose Login with a web browser. It opens GitHub, you paste a short code, you click authorize. Done.

You’ll see HTTPS and SSH mentioned everywhere as two ways to connect. The short version:

That’s the whole of authentication. You proved your Mac is yours, and you won’t think about it again until you switch computers.

You don’t need to learn git commands, because your agent runs them. You need the vocabulary, so that when Claude says “I’ll commit this and push,” you know what just happened and whether it was safe. Here’s the entire mental model in seven terms.

One more file worth knowing by name: .gitignore. It’s a plain text list of things git should pretend don’t exist. Build output, dependency folders like node_modules, and above all secrets and .env files. Anything listed there never gets committed, which is exactly how you avoid pushing an API key to the internet.

Your agent can run plain git on its own. These three additions give it more reach: an easy way to create and manage repos, and a direct line into GitHub’s issues and pull requests. Each is a single line to install.

The middle command installs the GitHub MCP for Claude Code specifically. If you use Codex, you get the same reach two ways: the gh CLI works identically for both agents, and Codex reads its own MCP servers from its config file (~/.codex/config.toml), where you can add the same GitHub server. Point is, your agent should do the GitHub work, not narrate it.

Take any project folder you already have. We’re going to turn it into a repo, make the first save point, and push it to GitHub. Open Terminal, move into your folder, and run these one at a time:

git init creates the hidden history. git add -A stages every file (marks it to be saved). git commit writes the first save point with a message. Now create the GitHub repo and push to it in a single command, courtesy of the CLI:

That makes a private repo on GitHub named my-project, links it to your folder as origin, and pushes everything up. Refresh GitHub and your code is there, history and all. Swap --private for --public if you want the world to see it.

Or skip every line of the above and let your agent do it. In Claude Code or Codex, inside the folder:

This folder isn’t on GitHub yet. Initialize a git repo, write a sensible .gitignore for this project, make an initial commit, then create a private GitHub repo and push. Tell me the repo URL when you’re done.

It will run those exact commands, ask permission along the way, and hand you back a link. Either path gets you to the same place: a real repo with your work safely backed up.

Once a project is on GitHub, daily life is a small loop you’ll repeat without thinking. Pull anything new, do your work, save it as a commit, push it up.

In practice your agent runs all four. Mostly you ask it to commit when you hit a good stopping point, and to pull at the start of a session if the project gets touched anywhere else.

Pull first is the rule I wish someone had drilled into me sooner. If the same project gets touched on two devices, say Claude Code on your Mac and again on your phone, pulling before you start saves you from the most common mess in git: two copies that drifted apart and now fight when you try to push.

And the one safety habit, before your very first commit on any project:

For a while, working straight on main and committing as you go is totally fine. You reach for a branch the first time you want to try something bold without risking the version that already works. A branch is a parallel copy: you experiment all you want, and main sits untouched until you decide the experiment earned its place.

A pull request (PR) is how a branch gets reviewed and folded back into main. It shows exactly what changed, gives you (or a teammate, or an agent) a place to look it over, and merges with one click when it’s ready. Even working solo, PRs are a clean way to see a feature’s full diff before it lands.

This is also where the more advanced agent workflows live. Claude Code can work on a branch in the cloud, push it, and open a PR for you to review, which means you can kick off work from your phone and approve the result later. Branches are what make that safe: the experiment is quarantined until you say yes.

The habit: anything experimental gets its own branch. Tell your agent to “do this on a new branch,” then look the PR over before you merge. Worst case, you delete the branch and main never knew it existed.

You’re going to hit a few of these. None of them are as dangerous as they sound, and the move for almost all of them is the same: paste the full message into your agent and ask what it means before doing anything.

Don’t wait for a fresh start. Take a project you already have, the one currently living in a folder you’d hate to lose, and put it on GitHub this afternoon. Four commands, or one brief handed to your agent. Fifteen minutes.

Then stack the habit on top: commit when you finish a thing, push before you shut the laptop. Once the work is safe, you’ll catch yourself taking bigger swings, because breaking something stopped costing you anything. That is the actual gift here. GitHub isn’t paperwork you tolerate. It’s the net that lets you be reckless on purpose.

You already did the hard part, which was deciding the terminal wasn’t going to scare you. Everything after this is just reps.