---
name: quiz-git
description: Quiz the user on git branching and the everyday commands, one question at a time, then score them. Use when the user asks to be quizzed or tested on git, branches, pull requests, or the basic git workflow — or says they've read the "Git, explained" explainer and wants to check it stuck.
metadata:
  category: quizzes
  tags: [quiz, git, branching, github, workflow]
  version: 1.0.0
  summary: Eight questions on branches, commands, and pull requests, scored, with what to re-read.
---

# quiz-git

Test whether someone can work in a repo without breaking prod. Companion to the
explainer at [bennybytes.net/explainers/git-explained](https://bennybytes.net/explainers/git-explained/).

## How to run it

1. Say what's coming in one line: eight questions, one at a time, scored at the end.
2. Ask **one question**, then stop and wait. Never show the next question, the answer,
   or the running score before they reply.
3. Mark their answer, then give **one line** on why. Credit a right answer in different
   words, and credit a correct command with different flags.
4. Keep a private tally. Ask the next question.
5. After eight, give the score and the verdict below.

Take the questions in order. If they're in a repo right now, use its real branch names
instead of the generic ones.

Don't run any git command during the quiz, and don't offer to fix their repo mid-way.
If they ask for help with a real problem, finish or abandon the quiz first and say so.

## Questions

**1. (multiple choice)** What is `main` for?
A. Your work in progress · B. What's live in front of users · C. A backup
→ **B.** It's prod. Nothing lands there except by reviewed merge.

**2. (short answer)** You're about to start work on a copy-link button. What's the first
command?
→ `git checkout -b feature/copy-link` (accept `git switch -c`). Cut from the latest
`main`. Credit anything that creates a branch before editing.

**3. (multiple choice)** You've edited three files. Put these in order: commit, add, push.
→ **add → commit → push.** Stage it, save it with a message, then send it up.

**4. (short answer)** What does a pull request actually do?
→ Asks for your branch to be merged into another one, and gives somebody a place to
review it first. It's a request plus a conversation, not a command.

**5. (multiple choice)** You've been on your feature branch for three weeks and `main`
has moved a lot. What's the problem?
A. Nothing, branches are free · B. The merge will be painful and risky ·
C. You'll lose your work
→ **B.** Branches are cheap; *long-lived* branches are expensive. Short branches are
the whole point.

**6. (short answer)** What's staging for, and who notices when it breaks?
→ A rehearsal copy of prod where the release gets tried first. Nobody outside the team
notices, which is exactly why it exists.

**7. (multiple choice)** Which is safe to do directly on `main`?
A. A one-line typo fix, it's tiny · B. A hotfix, it's urgent · C. Neither
→ **C.** "It's tiny" and "it's urgent" are the two sentences that precede most
outages. Branch, PR, merge — a small PR takes a minute.

**8. (short answer)** You pull and git says there's a conflict. What has actually
happened?
→ You and someone else changed the same lines, and git won't guess which wins. You open
the files, pick the right result, then add and commit. It's a question, not an error.

## Scoring

| Score | Say this |
|---|---|
| 7–8 | You can work in a repo safely. Next: `git log`, `git diff`, and how to undo things. |
| 4–6 | You've got the shape of it. Re-read the branch you got wrong, then do one real PR end to end. |
| 0–3 | Start with the explainer, then practise in a throwaway repo: init, branch, commit, push, PR. Nothing to break. |

Always close with the explainer link and offer the extra round.

## Extra round

Harder, for anyone who scored 7–8:

- You committed to `main` by accident and haven't pushed. Now what?
  → Move the commit onto a branch (branch from here, then reset `main` back). The key
  insight is that nothing is lost before a push.
- What's the difference between `git pull` and `git fetch`?
  → `fetch` downloads; `pull` downloads **and** merges into your branch. `fetch` first
  is the cautious habit.
- Why do teams protect `main`?
  → So the rule survives the day someone is in a hurry. Process you can skip under
  pressure isn't process.