Git for designers · Cheat sheet

Before you start: the loop, and questions for your developers.

Every team sets Git up a little differently. Keep the loop on hand, and take the questions below to a developer on your team before your first change. Ten minutes of answers saves a lot of guessing.

The designer's loop

One task, start to finish. Steps 1–5 happen on your computer; from step 6 your team is involved.

  1. PullGet the latest main before you start.
  2. BranchA new branch for this task, e.g. warmer-button.
  3. ChangeEdit tokens, styles, copy. Check the page.
  4. Commit+ to include, a short note, Commit. Repeat as you go.
  5. PushPublish the branch. Main is not changed.
  6. Pull requestAsk to merge into main. Say what and why; add a screenshot.
  7. Review & checksAnswer comments, fix on your branch, push again.
  8. MergeInto main. Often this is what ships it.

on your computerwith your teamtowards live

Questions to ask your developers

The answers decide what happens after you push. Write them down here or in your team's docs.

Is main protected?

Can anyone push to main directly, or must every change go through a pull request with an approval?

Where your change goes

Who reviews design changes?

Do I request a reviewer myself? Who, for tokens, components, copy?

Where your change goes

What checks run on a pull request?

Which ones must pass, and what do I do when one fails?

Where your change goes

Do pull requests get a preview link?

Can I see my change running somewhere before it's merged, and share that link?

Where your change goes

What happens when it's merged?

Does merging deploy automatically? To a test site first, or straight to production? Who merges: me or the reviewer?

Where your change goes

How do I see the project on my computer?

Which command or button starts it, and where do I open it in the browser?

Working in the code

Where do design decisions live?

Which files hold tokens, components and copy? Which files should I never edit?

Working in the code

How do we name branches?

Is there a pattern, like a ticket number or a design/ prefix?

How we work

How big should a pull request be?

One idea per pull request? How do I split a bigger change?

How we work

Who do I ask when I'm stuck?

A conflict, a failing check, a menu I don't understand: who's my person, and where do I ask?

When things go wrong

Something went wrong?

Find where your change is, then pick the matching action.

SituationDo this
You edited a file and want the old version back. Not committed.Discard Changes (right-click the file under Changes). It removes the edits, and recovery is not guaranteed, so copy anything you might need first.
The Status Bar says main, and you've changed files but not committed.Make a branch now (click the branch name in the Status Bar › Create new branch…). Your changes come along to the new branch.
You committed on main by mistake. Not pushed.Don't push. Ask a developer to help move the commit to a branch. If main is protected, a push to it would be refused anyway; if it isn't, it would go straight in without review.
You included (+) a file by mistake.Unstage it with the − next to it. Your edits stay.
Your last commit was wrong. Not pushed yet.Undo Last Commit (More Actions … › Commit › Undo Last Commit). The changes stay, staged, ready to commit again.
The commit is already pushed or shared.Revert the commit: a new commit that reverses it, without rewriting what others have. VS Code's docs do this with one terminal command (git revert), so ask a developer the first time. Already merged? A merged pull request can be reverted on GitHub.
A conflict after pulling or merging.Open the file, choose Accept Current, Incoming or Both (or use the merge editor), then finish the merge. If you're not sure, ask whoever made the other change.

Undo, discard and revert follow the Visual Studio Code documentation's "Undo or discard changes" table.